Current preview guide · Source on GitHub

How Codex Plus works

Codex Plus augments the native Codex CLI/TUI and continuing conversation. The
existing daemon owns model turns, goals, approvals and native tools. The watch
coordinator owns bounded observation, timers, event admission and receipts.

What is in the package

Codex Plus v0.1.0-preview.10 unifies workers, monitoring and reporting under one
version, source commit and release. Optional archives retain each component's
dependencies and configuration. Snap, Starship and Carbon select preview.10
artifacts from 078c630 following the scoped managed rollout on 2026-10-22.
Managed configuration, selected artifacts and already loaded processes
are different layers: existing MCP processes adopt new code on normal reconnect.
Journals, report data and hosting remain runtime-owned.

The read-only scripts/codex-plus-doctor reports selected manifest integrity,
enabled MCP configuration and native client/owner version evidence. Preview.10
can read reported MCP versions for one positively loaded conversation;
missing metadata remains unknown and reported versions do not verify payload
bytes. It never starts services or infers loaded code from a selected symlink.
A version outside the recorded qualification baseline remains unqualified; see
diagnosis.

Each canonical CODEX_HOME selects a native endpoint and Codex Plus context.
Explicit state/config paths take precedence; alternate homes otherwise derive
separate namespaces. Native --profile does not create another environment.
Peers and messages stay within that home's daemon, even on the same host.
Reports use the selected config/store and distinct configured serving endpoints.
See multiple environments for diagnostics and compatibility.

Native Codex/terminal notification delivery is outside Codex Plus. There is no
relay, completion hook or notification enrichment dependency. Formatting belongs
to Kitty/chezmoi; the old delivery/349 inspector work is retired.

Worker identities and explicit invocation behavior are unchanged. Discussing a
skill or asking for a generic goal loop does not invoke a worker workflow. The
HTML report skill is an additional skill, separate from the four worker workflows.
The worker guide covers Luna, task versus goal-loop workflows,
adaptive routing and the distinction between workers and independent peers.

Observation and follow-up

Registration freezes the caller, thread, owner and source identity. The runtime
positively verifies the loaded independent caller and native listener; it does
not launch another daemon or cold-resume a target. A private user-owned 0700
state root holds intent and event receipts outside model context.

Command sources inherit the exact calling session's effective execution policy,
including existing network access and authorized cache writes. Read-only and
network-off options narrow access; network-required checks an existing grant.
A repeated short command or continuing script can filter observations without
inference per read. JSON projection is optional; occurrence streams have different
semantics and are not deduplicated merely because lines have identical text.

Configured MCP checks take another route: the coordinator schedules a native
model turn, which inspects the selected registration and calls the actual tool
through normal authentication/approval. Each check costs a model turn. The
direct app-server MCP RPC is excluded because controlled qualification exposed
an approval bypass. No background helper invents missing credentials or grants.

Useful events queue into the exact continuing conversation. Busy delivery and
human control retain native ordering. The model reads fresh relevant state,
records handling and decides the next useful step under the existing request.
An observation supplies data, not permission to repair a workload or start a task.

Discovery and messaging

Ordinary peers are positively classified independent, loaded sessions within the
same daemon. Known children and unknown classification are excluded from ordinary
selection. Project/recent agent context helps resolve a description; ambiguity
or incomplete coverage is exposed. Peer reads omit user prompts and tool outputs.
Stable references never retarget when a name is reused.

Information and requests are attributed. The receiver can accept or decline a
request within its existing task. The sender reads cached handling receipts
instead of creating acknowledgement ping-pong. Outgoing cancellation can reconcile
pending intent but cannot interrupt the recipient or retract completed handling.
This is coordination between independent sessions, not subagent orchestration or
cross-host transport. Agent Observer/Mesh is not a runtime dependency.

Control and receipts

Explicit stop forbids renewal/replacement. Renewal retains the frozen source.
Recovery is explicit, retains remaining bounds, discloses gaps and does not replay
uncertain admitted events. The runtime does not claim exactly-once processing,
replace the native owner or intercept /exit with a confirmation dialog.

Returning to unfinished work

Preview.10 composes a recap from the existing watch/reminder
journals and sender-owned outgoing references. Reminder history is paginated;
outgoing receipts include their kind and a bounded quoted purpose. This is the
bound conversation's recorded work, with cached evidence and coverage limits.
It neither inventories every session nor starts new observation.

Fulfilled reminder delivery intent can precede completion of its native
follow-up turn. Acknowledgement records receipt. Pending or unknown outcomes
stay visible, including consumed callbacks after cancellation. Failed/interrupted
turns need attention until explicit reminder cancellation; terminal receipts
remain in history. Missing terminal evidence remains unknown even after a
coordinator exits. Inspection does not retry or infer success. Uncertain delivery
or withdrawal remains visible independently of that attention state.

See the daily recap example,
release availability and
the review evidence.

Coverage of the studied Claude workflow

Bryan's sampled Claude histories supplied the sequence: observe, wake, inspect,
decide, take an authorized action, continue and report. They included repeated
script-based watches, later checks and independently inspectable conversations.
That is historical mechanism evidence, not an audited production-outcome sample.
The context study retains the sanitized counts.

The official Claude documentation snapshot, checked 2026-10-14, describes command or WebSocket
Monitor sources, deadline notices and explicit cancellation. Its scheduling docs
describe adaptive loops and recurring/one-shot tasks, with a distinct Esc rule
for a waiting self-paced loop. These are comparison references, not Codex Plus
defaults. Monitor,
scheduling.
Claude documents background-task cleanup on exit; Bryan's reported confirmation
dialog remains user-observed behavior rather than a reproduced test here.
Background commands.

Codex Plus covers the studied workflow functions within its qualified scope.
Operational equivalence still needs real-source, longer-duration and personal UX
evidence; feature availability alone does not establish it. A built-in WebSocket
adapter, recurring calendar, cross-host transport and native exit interception
are not part of the current preview.

Where the evidence lives