# QNE Codex Development Network Agent Doctrine V1

Status: current operational doctrine

Date: 2026-06-23

## Scope

This doctrine applies to Codex running on the founder device, platform test
devices, and development cloud instances during the `qne-node-v00600`
development-network bootstrap.

## Core Rule

Codex can be installed and checked by QNE automation, but Codex account sign-in
remains local and manual on each device. QNE tools must not copy, sync, back up,
or transmit Codex `auth.json`, refresh tokens, API keys, Pro credentials, or
browser login sessions.

## Device Status

Each device may report one of three Codex states:

- `missing`: Codex was not found on the device.
- `installed-not-signed-in`: Codex is present but local sign-in is not ready.
- `ready`: Codex is present and local auth appears ready.

Status reports may record file presence and command availability, but not secret
content.

## Approval Envelope

Remote Codex work should use a QNE approval envelope:

- Routine read/status actions can run under narrow capability grants.
- Toolchain installation, package manager mutation, service installation, and
  network publication need explicit approval or a pre-approved qneskill policy.
- Destructive operations require local human approval unless a signed, narrow,
  revocable policy exists for that exact operation class.
- Approval requests and responses should travel as QNE messages and be persisted
  as audit records.

## qneskill Boundary

A Codex qneskill should handle prompts, responses, action requests, action
results, and approval records as QNE messages. Many payloads may be plain
strings, but the operational boundary is still the qneskill message/action
interface.

## Development-Network Use

The first development network uses qne-nodes only. Codex presence is a device
capability reported by each node; it is not a user identity system and does not
issue QNE user IDs.
