Verifiable tool-free single-request mode with offline invocation plan and usage ceiling

Feature request

Add a verifiable tool-free, single-provider-request mode to codex exec.

This complements #6049. An empty native-tool allowlist is necessary, but controlled automation also needs to prove before contact that the resolved request has no tools and cannot retry, reconnect, or continue into a second provider request.

Current gap

On the OpenAI-signed ChatGPT desktop bundle for macOS (codex-cli 0.151.0-alpha.7.1):

• features.shell_tool=false takes effect, but --disable unified_exec and features.unified_exec=false still leave unified_exec reported as enabled;
• bundled model metadata still advertises unified_exec, freeform apply_patch, and web-search tool types;
• debug models, debug prompt-input, and features list cannot run with --strict-config;
• there is no documented whole-invocation provider-request ceiling or offline effective-request manifest; and
• documented retry settings are provider-scoped and do not provide a stable CLI contract for the selected built-in ChatGPT-authenticated provider.

All observations above are provider-free and reproducible with an empty CODEX_HOME.

Requested contract

Equivalent stable controls would be:

codex exec \
  --no-tools \
  --max-provider-requests 1 \
  --request-max-retries 0 \
  --stream-max-retries 0 \
  --max-input-tokens 40000 \
  --max-output-tokens 40000 \
  --max-chatgpt-credits 30 \
  --require-invocation-plan-sha256 <digest>

And a provider-free diagnostic using the same production request builder:

codex debug invocation-plan \
  --offline --bundled-models --strict-config --ignore-user-config \
  --no-tools --max-provider-requests 1 \
  --request-max-retries 0 --stream-max-retries 0 \
  --max-input-tokens 40000 --max-output-tokens 40000 \
  --max-chatgpt-credits 30 \
  --model <model> --json

The canonical plan should report:

• resolved model, provider, and authentication kind;
• effective configuration and model-catalog digests;
• every outbound tool definition and its source;
• tools: [] and tool_choice: "none" under --no-tools;
• the provider-request ceiling and effective retry counts;
• the exact assembled input-token count, the output ceiling including reasoning,
  the applicable ChatGPT credit rate, the worst-case debit, and the currently
  available allowance;
• rejected or unknown configuration; and
• a canonical plan digest.

exec should recompute the plan before authentication/network access and fail if it differs from --require-invocation-plan-sha256.

Enforcement semantics

• Apply --no-tools after aggregating built-ins, shell/unified exec, patch, web/browser, apps, MCP/plugins, code/image/computer, dynamic, and subagent tools.
• Enforce the request budget at the common transport boundary before the initial request, HTTP retry, SSE/WebSocket reconnect, tool-result follow-up, or internal continuation.
• Once one request is reserved, a second attempt must fail before opening another socket.
• Retry overrides must apply to the resolved built-in ChatGPT provider.
• Reserve the worst-case ChatGPT usage before provider contact. Refuse if the
  assembled input exceeds its ceiling, the output ceiling cannot be transmitted
  and enforced, the applicable credit rate or remaining allowance is unavailable,
  or the remaining allowance is below the requested reservation. Reconcile the
  actual aggregate token and credit use after the attempt.

Acceptance tests

1. Capture serialized outbound JSON and assert an empty tool array and tool_choice=none.
2. Attempt to add every tool source under --no-tools; require pre-contact failure.
3. Simulate HTTP failures, stream interruption, reconnect, and tool/follow-up output; assert the mock provider sees at most one request.
4. Prove the offline plan and execution use the same request builder.
5. Mutate config after plan generation; require digest mismatch before auth/network.
6. Run the offline command with empty CODEX_HOME, missing auth, and denied network; require deterministic identical JSON.
7. Provide insufficient remaining allowance; require pre-contact refusal, then
   verify successful runs reconcile actual aggregate usage against the reservation.

Why the controls belong together

An OS sandbox can block tool effects, but it cannot prove the CLI did not make a second provider request after a denied tool call. JSONL rejection is also post-contact. The enforceable boundary is therefore: zero outbound tools, one provider request maximum, zero retries, pre-authorized worst-case subscription usage, and an offline plan bound to execution.

Start at the codex exec and debug invocation-plan entry points, then trace the shared production request builder and common transport boundary named in the request. Use the listed acceptance tests to verify tool suppression, one-request enforcement, offline-plan determinism, digest validation, and usage reservation before contact.