Codex turns fail in Full access mode when an org-managed requirements.toml forbids danger-full-access, with only a generic error #25674

What happened

Codex refuses to start any turn through T3 Code. Every message in a Codex thread fails with:

The provider could not start this turn. Retry the turn; if it keeps failing, check the provider setup and server logs.

Retrying does not help. Switching the thread's access mode from Full access to Auto makes Codex work immediately.

Diagnosis

The machine has an admin-managed Codex requirements file (/etc/codex/requirements.toml, root-owned, deployed by the org) that restricts what clients may request:

allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

Codex also enforces this via cloud-managed requirements. The error text reads "set by enterprise-managed requirements".

T3's Codex adapter maps the full-access runtime mode unconditionally to approvalPolicy: "never" + sandboxPolicy: { type: "dangerFullAccess" } (apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts, codexRuntimeModeTurnDefaults, ~line 709 at v0.1.2). Both values fall outside the managed allow-list, so the Codex app server rejects turn/start with JSON-RPC -32600.

Two problems on the T3 side:

1. The real reason is hidden. packages/provider-core/src/server/failure.ts collapses the ProviderAdapterTurnStartError into the generic "could not start this turn" category message. The Codex message, which names the exact policy conflict, is only visible in the server logs. The suggested remedy ("Retry the turn") can never succeed.
2. T3 offers an access mode the Codex install forbids. The Codex app server exposes configRequirements/read (already in the generated client: packages/effect-codex-app-server/src/_generated/meta.gen.ts), but T3 never calls it. T3 could read the allowed sandbox modes and approval policies and then do one of three things: disable or annotate Full access for Codex, fall back to the strongest allowed mode, or at least show the requirement error to the user.

The same mapping is unchanged on main as of 2026-10-26 (still dangerFullAccess for full-access, no configRequirements usage). Enterprise users with a managed Codex policy hit this on every Codex thread, because Full access is the mode most threads are in. On this machine, 100 of 101 threads were Full access.

Steps to reproduce

1. On a machine with Codex CLI installed, create /etc/codex/requirements.toml containing:

   allowed_sandbox_modes = ["read-only", "workspace-write"]
   allowed_approval_policies = ["untrusted", "on-request"]

2. In T3 Code, start a new Codex thread with access mode Full access.
3. Send any message (e.g. test).
4. Observe: "The provider could not start this turn…" in the UI, and in the server log invalid value for sandbox_mode: DangerFullAccess is not in the allowed set [ReadOnly, WorkspaceWrite].
5. Switch the thread to Auto and resend: the turn starts normally.

Version

0.1.2 (local server, serverVersion from /.well-known/t3/environment)

Environment

Linux x64 (RHEL 9, kernel 5.14), Node v26.8.2, codex-cli 0.164.0; T3 server running on a remote dev box, desktop app connected over SSH

Evidence

[15:31:47.901] ERROR orchestration V2 provider turn start failed
  cause: ProviderAdapterTurnStartError: Failed to start run run:thread:<thread>:ordinal:1 on codex provider thread ...
    [cause]: CodexAppServerRequestError: invalid thread settings override: invalid value for `sandbox_mode`: `DangerFullAccess` is not in the allowed set [ReadOnly, WorkspaceWrite] (set by enterprise-managed requirements Default requirements (<id>))
      at CodexAppServerRequestError.fromProtocolError (t3:273122:11)
      at CodexAppServerProtocol.request (t3:295535:154)
      at CodexAdapterV2.startNativeTurn (t3:301089:15)
      at RunExecutionService.startRootRun (t3:371948:24)
      at ProviderTurnStartService.start (t3:372361:58)

# JSON-RPC: method "turn/start", code -32600
# Same failure for normal threads and for delegate_task Codex children (4 occurrences in ~12 minutes)

Related issues

#12248 (closed) and #17395 (closed, dup): Full access maps Codex to approvalPolicy: "never", which breaks prompted commands. They involve the same mapping, but this issue is about the turn being rejected outright by managed requirements and the error being masked. #21138 (closed) added per-launch sandboxPolicy overrides for launchThread, but that does not cover interactive threads or check requirements. No existing issue mentions requirements.toml or "enterprise-managed requirements".

Fix applied or workaround

No changes made on the machine. Workaround: switch Codex threads from Full access to Auto (maps to on-request + workspaceWrite, which the managed policy allows). The user confirmed this works.

Filed by

Claude Code (Claude Opus 5.5, claude-opus-5-5) via t3 triage