Full Access rejects repository inspection commands that Auto permits

What happened

Two repository-inspection command batches were rejected in a T3 Code Nightly Codex thread using Full Access:

exec_command failed: CreateProcess { message: "Rejected(\"approval required by policy, but AskForApproval is set to Never\")" }

Switching the same thread to Auto allowed both batches through automatic review. Local inspection succeeded. GitHub queries initially failed to connect with network disabled, then succeeded after an explicitly escalated retry received automatic approval.

Expected: selecting Full Access allows these repository-inspection commands to execute without approval prompts. T3 supplies sandbox: "danger-full-access" and approvalPolicy: "never"; never refers to asking for approval, not to permission to execute commands.

Actual: execution still requires approval, then fails because asking is disabled. The same commands proceed under Auto. Please investigate why the Full Access configuration does not deliver the selected behavior. Identifying a matching prompt rule explains a possible mechanism; it does not establish that the resulting Full Access behavior is correct. Better error wording alone would not resolve the reported execution failure.

Diagnosis

The original rollout confirms Full Access was actually never + danger-full-access + reviewer user. After the switch, both the rollout and T3's thread/settings/updated event confirm on-request + workspace-write + auto_review.

Local ~/.codex/rules/default.rules contains these relevant rules:

prefix_rule(pattern=["gh", ["push", "pull", "repo"]], decision="prompt")
prefix_rule(
    pattern=["jj", "git", ["clone", "colocation", "export", "import", "init", "remote", "root"]],
    decision="prompt",
)
prefix_rule(pattern=["jj"], decision="allow")

Codex 0.154.0's execpolicy check returns:

Command	Matching decision
jj status	allow
jj git remote list	prompt, despite also matching jj → allow
gh repo view <owner>/<repo> --json nameWithOwner,parent,defaultBranchRef	prompt

Each rejected batch includes a command matching prompt when the rule file is evaluated independently. This strongly supports a conflict between command rules and Full Access's disabled approval path. The standalone evaluator does not test the full danger-full-access + never runtime configuration, so it cannot establish whether that composition behaves as intended. The exact matched rule was not included in the original rejection; historical attribution remains an inference. Evidence does not yet establish whether the defect belongs in T3's integration or Codex's policy handling. No reversed enum mapping is claimed.

Tagged T3 mode mapping, start/resume/turn parameter construction, and installed server bundle agree. Codex rules documentation explains that the most restrictive matching decision wins and simple compound shell commands are evaluated per command. Codex approval documentation explains disabled prompts and automatic review.

Steps to reproduce

Observed sequence, verified from retained logs:

1. In an existing local T3 Nightly Codex thread with the rules above, select Full Access.

2. Submit these two batches as separate concurrent exec_command calls, with the repository as cwd and no sandbox override:

   jj status; jj git remote list; jj bookmark list; jj log -r 'main | main@origin | dev-mvp | @' --no-graph
   

   sed -n '79,81p' <absolute-local-markdown-path>; gh repo view <owner>/<repo> --json nameWithOwner,parent,defaultBranchRef; gh api repos/<owner>/<repo>/compare/<upstream-owner>:main...main --jq '{status,ahead_by,behind_by,total_commits}'
   

   Placeholder paths and repository identifiers above redact the original values; they must be substituted, not run literally.

3. Both calls fail before process creation with the quoted error.

4. Switch that thread to Auto and repeat. Both receive automatic approval; JJ and local file reads succeed.

5. Retry the GitHub queries with sandbox_permissions: "require_escalated" after their restricted-network failures. Automatic approval permits them and they succeed.

Verification independently repeated the per-command policy checks without executing the commands. A new end-to-end Full Access/Auto/Full Access test and isolated Full Access command executions have not been performed. Jujutsu inspection may update bookkeeping; no filesystem-read-only guarantee is claimed.

Version

Installed desktop bundle: 0.0.43-nightly.20260917.1851, release commit 0150c6a53b409ba3bcb45645709b649cf8708354. Loaded process build was not independently verified. The separate triage CLI context reported 0.0.40.

Environment

macOS 26.6.2 (25G83), Apple Silicon; zsh; Codex CLI 0.154.0; original rollout model gpt-6-astra. T3 Nightly desktop hosts the local server and Codex child process. Triage context reports Node v24.13.1; the desktop server's Node version was not separately checked.

Evidence

Times below are UTC on 2026-09-17. Selected fields are transcribed from the original rollout and provider notifications.

11:57:58.892 turn_context: never / danger-full-access / user
11:58:09.179 two tool calls rejected: approval required by policy, but AskForApproval is set to Never
12:35:30.961 thread/settings/updated: on-request / workspaceWrite / auto_review; networkAccess=false
12:35:51.306 item/autoApprovalReview/completed: JJ batch approved, risk=low
12:35:52.156 item/autoApprovalReview/completed: local-file/GitHub batch approved, risk=low
12:35:52.313 JJ/local file succeeded; GitHub requests: error connecting to api.github.com
12:36:06.935 item/autoApprovalReview/completed: escalated GitHub retry approved, risk=low
12:36:08.747 GitHub retry exited 0

Other file-inspection calls succeeded while Full Access remained active. The rule file's modification time predates the rejected batches; no historical rule snapshot was available.

Related issues

No matching issue identified in searches for the error, AskForApproval, execpolicy, and Full Access/rules. PR #9506 addresses managed requirements rejecting thread startup, a different failure. It was closed without merging. No newer release or relevant runtime commit was identified as fixing this behavior.

Fix applied or workaround

User switched the affected thread to Auto before triage; retained logs verify that workaround. Investigation made no policy/configuration changes and did not patch T3. Source clone and separate report files only.

Filed by

Prepared by Codex (GPT-6 Astra) via T3 triage.

Start with apps/server/src/provider/Layers/CodexSessionRuntime.ts at the referenced mode mapping, then trace the start, resume, and turn parameter construction. Reproduce the listed jj and gh command batches with the supplied rules under Full Access and Auto, and compare the resulting approval behavior. Done means establishing whether the failure is in T3 integration or Codex policy handling and covering the confirmed behavior.