provider-codex
Skill16 starsChanged 2 months agoMITView on GitHub
Track and maintain the upstream OpenAI Codex CLI contract. Use when OpenAI ships a Codex release, when a `codex exec` flag/sandbox/approval/resume/subcommand behaviour changes, or when an upstream scan flags drift. Process guidance only; `src/upstream-contracts.ts` is the mechanical source of truth.
In this repository19 other files it gives its agents.
- site/agents.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- site/llms.txtllms.txt
- async-job-orchestrationSkill
- implement-review-fixSkill
- least-cost-routingSkill
- multi-llm-reviewSkill
- personal-agent-config-kitSkill
- provider-claudeSkill
- provider-cursorSkill
- provider-devinSkill
- provider-geminiSkill
- provider-grokSkill
- provider-mistralSkill
- public-demo-sessionSkill
- retrospective-walkSkill
- secure-orchestrationSkill
- session-workflowSkill
- supply-chain-guardSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 0 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 49
Use codex_request for normal implementation/review turns and codex_request_async for long-running work.
- Very specific: line 61
Prefer sandboxMode:"workspace-write" when Codex needs a writable workspace.
- Very specific: line 66
Do not pass Claude-style allowedTools or disallowedTools.
- Very specific: line 70
Use sandboxMode, profile, configOverrides, oss, images, outputFormat, and outputSchema only as reported by provider_tool_capabilities.
- Very specific: line 114
Follow multi-llm-review's full-access protocol, inspect the current request schema and live capability response, and use a fresh …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Provider: OpenAI Codex CLI
Process guidance for keeping the gateway's Codex (codex) integration aligned
with the upstream CLI. This skill does not define argv/env behaviour; the
single mechanical source of truth is UPSTREAM_CLI_CONTRACTS.codex in
src/upstream-contracts.ts, enforced by validateUpstreamCliArgs /
validateUpstreamCliEnv. Never re-encode flags, sandbox/approval modes, or
resume rules here or in TOML.
Identity
| Field | Value |
| CliType | codex |
| Executable | codex |
| Package | @openai/codex (npm) |
| Repo | https://github.com/openai/codex |
| Release API | https://api.github.com/repos/openai/codex/releases/latest |
| Changelog RSS | https://learn.chatgpt.com/docs/changelog/rss.xml |
| Watch categories | flags, sandbox-modes, approval-modes, session-resume, output-schema |
These values mirror UPSTREAM_CLI_CONTRACTS.codex.upstreamMetadata and
docs/upstream/provider-sources.dag.toml ([providers.codex]). The TypeScript
metadata is authoritative; the TOML is scanner input only.
When to use
- An OpenAI Codex CLI release lands and you need to check for contract drift.
- A
codexrequest fails the upstream contract check before spawn. npm run upstream:scan -- --livereports a change on the Codex release notes or changelog.
How LLM agents should use Codex through the gateway
- Discover the live gateway/provider surface before relying on Codex-specific
controls:
For a cached read-only resource, useprovider_tool_capabilities({cli:"codex"})provider-tools://codex. - Use
codex_requestfor normal implementation/review turns andcodex_request_asyncfor long-running work. To continue an existing Codex conversation, passcodex_requesta real Codex session UUID from~/.codex/sessions/, orresumeLatest:true; both route throughcodex exec resumeand work headlessly.codex_fork_sessionis registered but cannot run from the gateway:codex forkis interactive and requires a controlling terminal, and Codex exposes no non-interactive equivalent (codex exechas only resume/review/help). Re-check that on each Codex release; if a headless fork lands,codexForkCanRunHeadlessinsrc/index.tsis the single predicate to flip. - Omit
modelunless the caller explicitly asked for a specific variant; the gateway resolves the configured Codex default/profile. - Prefer
sandboxMode:"workspace-write"when Codex needs a writable workspace.fullAuto:trueis the deprecated compatibility shorthand. UseapprovalStrategy:"legacy": Codex rejectsmcp_managedbefore launch because its ambient MCP configuration cannot be isolated, andapprovalPolicyhas no effect for Codex. - Do not pass Claude-style
allowedToolsordisallowedTools; Codex does not expose those request fields through the gateway. Codex owns its MCP configuration, and a gatewaymcpServerslist is descriptive metadata, not an enforceable allowlist. - Use
sandboxMode,profile,configOverrides,oss, images,outputFormat, andoutputSchemaonly as reported byprovider_tool_capabilities.askForApprovalanduseLegacyFullAutoFlagare deprecated compatibility inputs: current Codex emits no corresponding argv and the gateway returns a warning.fullAuto:trueremains a compatibility shorthand forsandboxMode:"workspace-write". These are provider-native legacy controls, not inputs to the Claude-only gateway approval boundary. - Codex continuity is real through
codex exec resume: pass a real Codex UUID from~/.codex/sessions/, orresumeLatest:true. Gatewaygw-*IDs are not Codex sessions.sandboxModeand its deprecatedfullAuto:trueshorthand are dropped on resume, so those fields cannot select a posture there. That is not a guarantee that the original posture is retained:configOverridesis not filtered and can setsandbox_mode, and Codex re-resolves configuration on a cold resume.resumeLatestis under review (#258):--lastis cwd-filtered upstream unless--allis passed, which the gateway does not emit, and the child is still spawned with the gateway-resolved cwd. Do not rely on which session it selects or on the resumed working directory. The provider-nativeworkingDirandaddDirflags scope new sessions only; the gateway accepts but omits those fields on resume. Omitting them does not pin the resumed directory: the child is still spawned with the gateway-resolved cwd. A verifiedworkspaceor gatewayworktreecan still select the child process launch cwd and bind gateway tracking. Do not rely on a resumed session's directory in any resume form, including a direct UUID resume: the child is spawned with the gateway-resolved cwd even though the flags are filtered. - Codex new and resume requests send the exact prompt through stdin with the
native
-marker. They do not consume the platform's single-argv prompt allowance and are never truncated.codex_fork_sessionuses the distinctcodex forkcontract, remains argv-bound, and rejects oversized UTF-8 prompts as non-retryableinput_too_large. That rejection is deliberately evaluated before the tool's availability check, so argv admission stays observable even though the call cannot ultimately run. An otherwise unscoped child still runs in a fresh neutral temporary cwd, not the gateway repository. All other caller-controlled argv values are admitted in their final encoded form before spawn. Embedded NUL bytes return non-retryableinvalid_inputwithout exposing the rejected value. New and resumed stdin requests complete only after the full payload write callback succeeds; a clean child exit with closed or pending delivery is a fixed non-sensitive failure.
Full-access review handoff
For a user-authorized exhaustive review that needs full provider permissions and
native MCP access, do not infer the launch controls from this maintenance guide.
Follow multi-llm-review's full-access protocol, inspect the current request
schema and live capability response, and use a fresh target-checkout
node dist/index.js --transport=stdio gateway rather than a global process.
Reapply the grant on every new job, preserve native MCP configuration without a
pretend gateway allowlist, send the corrective-program report and exact
diff/file identity, set no caller caps, and honor a user-required 90-second
progress cadence. The reviewer must independently inspect code, docs, tests,
and commands before it can approve.
Scan for upstream change
npm run upstream:scan -- --provider codex
npm run upstream:scan -- --live --provider codex --fail-on-critical
npm run upstream:scan -- --live --provider codex --write-snapshot --write-reportA failed fetch is advisory (exit 0) unless --fail-on-critical is passed.
Update procedure when the upstream CLI changes
- Edit the contract in
src/upstream-contracts.ts(UPSTREAM_CLI_CONTRACTS.codex): theexec/exec resumecommand shape, flag arities/enums, and theresumeOnlyFlags/resumeForbiddenFlagslists all live here. - Add a conformance fixture proving the new accept/reject behaviour
(mirror the existing
codex-*fixtures, including resume cases). - If a source URL or watch category changed, update
upstreamMetadataand mirror it intodocs/upstream/provider-sources.dag.toml. - Verify:
npm run build && npm run upstream:contractsandnpm test.
Codex-specific notes (see the contract for exact rules)
- Tested against codex-cli 0.153.0. Codex advertises mcp-server / app-server transports, not a native ACP entrypoint, so
provider-acp://codexreportsnative:false(no methods, no adapter-as-native masquerade) andcodex_requestexposes notransport:"acp"selector. - argv must start with
exec;exec resumeenters resume context. --lastis resume-only. In resume context,--sandbox,-C,--cd,--add-dir, and--profileare forbidden (perresumeForbiddenFlags).--ask-for-approval,--full-auto, and--searchare unsupported by the currentcodex execcommand on every path.--output-schema,-c key=value,--ephemeral, safety bypasses (on review),--jsonetc. are accepted on resume/review (codex-cli 0.153.0). Example (resume):codex exec resume --ephemeral --json <UUID> "follow up"- Sandbox and approval values are closed enums; extend the enum in the contract.
- Continuity is real via
codex exec resume <UUID>/--last;sessionIdmust be a real Codex UUID (gatewaygw-*IDs rejected). - Top-level interactive
resumeand destructivedeleteare catalogued for drift monitoring, not request argv. Keep them unexposed unless a separately reviewed gateway surface is added.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

