Current preview guide · Source on GitHub
Get started with Codex Plus
Choose the part that helps your work: delegate a task, follow a running job or
publish a browser handoff. One Codex Plus release supplies optional component
archives and keeps native Codex as your daily interface.
Choose what to install
| You want to… | Install | First request |
|---|---|---|
| Delegate investigation or implementation | Worker agent definitions and workflow skills | $luna-task Investigate the importer failure and return a reproduction. |
| Follow work, coordinate sessions or check later | Monitoring runtime and its codex_plus MCP configuration |
“Watch this run and tell me if it stalls or fails.” |
| Share findings in a browser | Reporting runtime, hosting configuration and report skill or html_report MCP |
“Make a browser report of the results, including the risks.” |
Workers use native agent tools. Monitoring provides 15 MCP tools for observation,
peer communication and later checks. Reporting provides four tools and an
independent static report store. Installing one component does not install the
others.
Workers, monitoring and reporting use the same version and source commit in each
release. Choose the archives you need from its single GitHub release; see
release verification.
Released and source features
v0.1.0-preview.10 supplies all workflows shown in these guides. Updating
documentation or selecting an archive does not reload an existing MCP process.
| Available in | What to expect |
|---|---|
| Preview.9 and later | Worker workflows, watches, one-shot later checks, same-daemon peer coordination, reports and selected-file diagnosis. |
| Added in preview.10 | Bounded reminder history, outgoing-message rediscovery with kind and quoted purpose, pending/failed follow-up visibility, and reported MCP-version diagnosis for one loaded conversation. |
The “What am I still waiting on?” example uses preview.10's inspection
improvements. See daily use for its
behavior and the review results
for evidence and limits. Existing preview.9 artifacts retain their original
contents; choose the new release through your installation's configuration owner.
If your setup is already managed
Use the configuration manager that owns your agent, skill and MCP files. For
Bryan's Snap, Starship and Carbon installations, that is chezmoi. Open a fresh ordinary
session in the intended environment and use a request from the table above.
Existing explicit opt-outs remain effective. Loaded processes adopt selected
code on normal reconnect; updating documentation does not update them.
On Snap, codex selects personal/OSS work and codex-work selects work. Their
conversations, tools, follow-up state and reports use separate contexts. See
environment selection for the managed paths and portable
CODEX_HOME behavior. Choose that environment before starting a task.
Set up workers
Install the luna-max and sol-xhigh agent definitions and the four worker
workflow skills using the worker installation steps.
Your client and account must support custom agents, skills and the selected
models. The intended primary is Sol XHigh; workflows keep your current primary
selection.
Start with $luna-task for one bounded assignment. Use $luna-goal-loop for a
substantial goal with Luna, or the adaptive $worker-task / $worker-goal-loop
workflows when the primary should choose useful delegation. Your primary owns
decisions and review. Generic “goal loop” wording does not select a worker.
Set up monitoring and coordination
The monitoring installation guide covers verified
release archives, immutable installation and MCP configuration. The preview
targets Linux/Unix, Python 3.11 or newer and RTK. The release qualification
baseline is Codex 0.162.1. This release also includes bounded owned trials on
0.163.0; neither result establishes compatibility with every newer client.
Integrate the generated MCP table through your configuration owner. Once loaded
in a native conversation, ask for a useful update from a source your session
can already access. Peer coordination needs independent loaded sessions within
the same owning daemon. See daily use for
discovery and handling receipts.
Set up reporting
The report guide covers the separate report artifact,
MCP or CLI entry point, store and serving configuration. Its Python runtime does
not require a native agent owner. Optional automatic hosting uses tmux; an
external HTTP server can also serve the configured public subtree.
Configure a report URL reachable from your viewing desktop. Publication stores
an immutable snapshot; a delivery check verifies HTTP bytes; opening it in your
browser verifies the presentation. These are separate results. Publishing a
report does not publish a GitHub Pages site or make a private endpoint public.
Try one useful request
Use work already in front of you. Give a worker a concrete outcome and acceptance
check, describe the change you want a watch to report, or ask for a browser
handoff of actual findings. You can inspect registrations and explicitly stop a
watch. Esc interrupts the foreground turn while independent observation remains
within its bounds.
Continue with everyday requests, explore the
illustrative walkthrough, or read
how the components fit together. The
daily-use checklist helps record useful outcomes and friction
without treating bounded synthetic checks as long-term reliability evidence.