PaperClipAI/packages/paperclip-runner/docs/codex-driver.md

Codex Skillless Codex Driver

Scope

Codex implements a direct Codex app-server v2 driver behind the package's existing HarnessDriver contract. The driver, mock core, example CLI, tests, and evidence stay inside packages/paperclip-runner/. They do not import or change Paperclip server, UI, database, or production control-plane behavior.

The app-server process is local to the execution environment and uses newline delimited JSON-RPC over stdio. It is not exposed as a network service.

Identity mapping

Runner identity	Codex source	Persistence rule
run ID	mock-core input	Never replaced during recovery.
normalized session ID	controller-owned mock-core input	A distinct identity, independent of the run and provider IDs, that stays stable across transport/process recovery.
driver session ID	thread.id	Resumed by exact ID. A different returned ID fails recovery.
provider session ID	thread.sessionId	Kept separately from the driver thread ID.
turn ID	turn.id	Required by steer and interrupt preconditions.
item ID	item.id, request ID, or deterministic turn/kind key	Preserved on lifecycle and delta events.
source event ID	runner instance + run + source sequence	Source sequence continues from the persisted snapshot.

The persisted session snapshot records run, normalized session, driver session, provider session, the exact active turn, committed semantic-result content/call binding, observed terminal-turn fingerprints, and the last source sequence. Recovery starts a new local app-server transport, reads the exact persisted thread to validate identity and working directory, resumes that thread, and then reads it again for reconciliation. Reconciliation considers only the persisted active turn: it retains that turn when active, terminalizes that turn when terminal, and fails recoverably when it is missing or a different active turn appears. Historical terminal turns never substitute for the persisted active turn, and a terminal already in the durable snapshot is not emitted again.

App-server operations

Driver operation	App-server method	Degradation
initialize	initialize, then initialized	Startup fails visibly.
create	thread/start	Required.
resume	thread/resume	recovered: false with a redacted reason.
read	thread/read	Explicit HarnessCapabilityUnavailableError.
start turn	turn/start	Required.
steer	turn/steer with expectedTurnId	Explicit unsupported diagnostic; no stdin fallback.
interrupt	turn/interrupt	Explicit unsupported diagnostic; session is not killed.
usage	thread/tokenUsage/updated	Returns the last snapshot or explicit unsupported error.
reconcile	thread/read plus session.reconciled	Disabled when read is unavailable.

Capability flags are descriptive and executable. Unsupported operations emit canonical harness.diagnostic events with secret-redacted detail. No harness-specific branch is required in the mock core.

Skillless context boundary

The model receives one text input containing paperclip.skillless_task.v1:

• objective;
• completion-contract revision and criteria;
• task constraints; and
• the expected canonical result schema name.

The thread config explicitly disables automatic skill and app instruction blocks. Codex's built-in collaboration instructions are enabled by default so interactive runs receive native commentary and tool preambles; a driver caller may explicitly disable them for a specialized deterministic fixture. This does not enable skills, apps, plugins, memories, or extra model-input kinds. The model input accepts only text, never a Codex skill input. The driver captures the returned instruction-source list and requires it to be empty for the skillless assertion.

The trusted app-server process has an allowlisted environment. It retains host HOME and CODEX_HOME only so the provider can authenticate. Model-issued commands have a separate boundary: an empty-by-default environment with no HOME or CODEX_HOME, no network, and a named Codex permission profile requesting read-only minimal runtime files, no host-home or Codex-home access, and write access to the assigned workspace. The driver refuses filesystem-root workspaces, workspaces containing host HOME, and any workspace overlapping host CODEX_HOME. A workspace below host HOME is valid, but when PAPERCLIP_WORKSPACE_CWD is present its canonical path must be equal to or below that assigned workspace so sibling and symlink escapes fail before provider startup.

When the execution target is itself the sandbox (a remote sandbox such as Daytona sets PAPERCLIP_RUNNER_EXTERNAL_SANDBOX=1), standard and ask runs use the default execution mode. The Runner starts their Codex threads and turns with the external sandbox policy and sends no collaboration mode. Ask mode restricts Paperclip mutation tools, not the Codex sandbox. Planning runs keep the paperclip-runner-workspace-read-only profile on thread/start and turn/start everywhere, because Codex's plan collaboration mode is a prompt and does not block writes or commands. Inside an external sandbox that profile reads the whole filesystem (":root"="read"), writes nowhere except a brokered GitHub CLI config directory, and keeps the controller's network decision (PAPERCLIP_RUNNER_NETWORK_ACCESS). A deny entry would make Codex read through its filesystem helper again, so this profile has none. Codex then reports a readOnly sandbox, loads AGENTS.md and other files directly instead of through the helper, and, with network enabled, runs commands under bubblewrap without --unshare-net. The helper always isolates the network, and a container without CAP_NET_ADMIN cannot bring up loopback in a new network namespace (bwrap: loopback: Failed RTM_NEWADDR), which made thread creation fail. Writes from commands and patches are still refused. When the controller disables network, the thread still starts, but bubblewrap must isolate the network, so planning commands fail closed in such a container. On the current Daytona image, bubblewrap also cannot map user IDs for planning commands (bwrap: setting up uid map: Permission denied), so shell commands fail closed there in every planning turn. The planning turn still reads files and writes its Plan through Codex and Paperclip tools. The broader read access matches what default-mode turns already have in the same sandbox, and the session context records rootAccess: "read" for these planning turns. Local and SSH planning keep the narrower profile that denies host HOME and CODEX_HOME. If a remote target still refuses provider startup, the run ends as a provider startup failure with Retry (see durable-recovery.md).

The returned sandbox facts remain authoritative. Codex 0.132.0 may inject a provider-managed writable root such as ~/.codex/memories after a first run, even with features.memories=false and an explicit Codex-home deny. That makes the Codex-home directory discoverable in a warmed environment, so Codex does not claim whole-directory unreadability. Its authenticated proof instead requires each readable auth.json/config.toml file and an unrelated host secret to remain unreadable and unwritable, while recording any injected root in context.sandbox.legacyPolicy.

Paperclip bearer values, OPENAI_API_KEY, arbitrary skill paths, and other inherited variables are not passed. Diagnostics redact bearer/basic credentials, credentialed proxy URLs, secret query parameters, sensitive JSON keys, and common key assignments.

The context snapshot records configuration and environment key names, not secret values.

Semantic completion

The provider-facing structured-output schema covers done and needs_review. It uses the strict OpenAI shape: every object rejects additional properties and the constant schema field includes both type: "string" and const.

Two dynamic semantic tools are registered when supported:

• paperclip_finish accepts done or needs_review;
• paperclip_block accepts blocked and requires a blocker owner, action, reason, and scope.

Both normalize through the canonical paperclip.run_result.v1 validator. The first valid result is proposed. Any canonically identical result retry is idempotent even when the provider assigned a new call ID; the original call binding remains persisted for audit, while changed content is rejected. Tool calls and provider notifications must name the exact opened thread and active turn. Missing, pre-turn, cross-thread, cross-turn, and post-terminal bindings fail the provider session closed. Canonically identical terminal replays are no-ops; conflicting terminal facts are rejected. Process exit or prose alone never implies completion.

The provider cannot commit controller state. It emits run.result.proposed and a provider turn terminal; the mock core validates the proposal against its task envelope, emits run.result.accepted or run.result.rejected, and alone emits run.terminal.

Canonical event mapping

• thread lifecycle -> session.started, session.resumed, session.reconciled;
• turn lifecycle -> turn.submitted, turn.accepted, turn.started, and one terminal turn event;
• messages, reasoning, plans, commands, file changes, dynamic tools, and diffs -> item.started, item.delta, item.completed;
• model selection -> a completed model item;
• app-server decisions -> runtime_request.created and runtime_request.resolved with redacted detail;
• token snapshots -> completed usage items;
• semantic verification rows -> completed verification items;
• provider completion -> at most one run.result.proposed and one turn terminal;
• controller decision -> one run.result.accepted or run.result.rejected, followed by one run.terminal.

The JSON-RPC transport limits each input line, pending client requests, in-flight server requests, queued notification count and bytes, diagnostic lines, and retained provider payloads. Malformed or oversized messages close the transport and reject pending work.

The existing Replay reducer consumes the live stream. Replay crosses a serialized JSONL boundary that validates byte and event counts, line size, schema, run/session binding, unique source event IDs, continuous per-source sequence, and exactly one final run terminal before reducing. The Codex tracer requires byte-equivalent live and replay snapshots.

Runnable example

trace:codex starts a real local codex app-server session through the mock core. Its safe task creates hello.txt with network disabled. The evidence recorder additionally probes all readable host Codex credential/config files and an unrelated host secret, requiring reads and writes to be denied while workspace output and app-server authentication still succeed. It gates output reads on an accepted done result and reports missing files by name rather than surfacing a raw filesystem ENOENT. See the Codex tutorial.

This phase changes no browser surface, so no new browser screenshot applies. The canonical events are proved through the existing reducer/replay path and JSON trace evidence.

Explicit assigned skills in native tasks

A task description can explicitly invoke an assigned skill with /skill-name or $skill-name. The native Codex backend resolves these references against that run's assigned runtime context; assignment alone does not invoke a skill. Selections are recomputed from the current task description on each wake, including approval replies and recovered sessions. Ordinary tasks without an explicit reference receive no structured skill invocation.

The driver sends both the $skill-name text reference and Codex's structured { type: "skill", name, path } input on every requested turn. Runnerd validates the assigned source path, maps it to the provider's isolated codex-home/skills/<name>/SKILL.md (including remote runners), and preserves it through the durable turn.start command. turn.submitted.skillInputs records the controller's selected inputs for inspection; protocol tests separately verify the outgoing provider request and mapped path.

includeSkillInstructions is forwarded to Codex on both thread/start and thread/resume. Old persisted configurations without the field retain their provider default until a fresh, settled run supplies an explicit value. That one-time upgrade reopens the same thread with the new setting. OpenCode does not receive Codex's skill configuration or structured skill inputs.

These are delivery guarantees, not guarantees of model adherence. The onboarding first-task skill uses this generic mechanism; its prompt and persona are not changed by the wiring.