Repository navigation
Full Access rejects repository inspection commands that Auto permits #12248
Description
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:
-
In an existing local T3 Nightly Codex thread with the rules above, select Full Access.
-
Submit these two batches as separate concurrent
exec_commandcalls, 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.
-
Both calls fail before process creation with the quoted error.
-
Switch that thread to Auto and repeat. Both receive automatic approval; JJ and local file reads succeed.
-
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.
Activity
juliusmarminge commentedon Sep 17, 2026
Triage
Confirmed. T3 Full Access is sending the intended Codex preset (
approvalPolicy: "never",sandbox: "danger-full-access",approvalsReviewer: "user"). Codex then hard-rejects commands that match a user execpolicypromptrule, becausenevercannot ask. This is the same conflict Codex Desktop hits.What T3 is doing
runtimeModeToThreadConfigmaps:neverdanger-full-accessuseron-requestworkspace-writeauto_reviewThose values are applied on
thread/start,thread/resume, and everyturn/start. The retained rollout matches that mapping (11:57:58Full Access,12:35:30Auto). There is no reversed enum mapping.UI and docs describe Full Access as “Allow commands and edits without prompts” (web, mobile, permission modes). That is the selected behavior the user expected.
Why those batches died
Local
~/.codex/rules/default.rulesincludesprefix_ruleentries withdecision = "prompt"forgh … repoandjj git … remote. Codex rules take the most restrictive matching decision (promptbeatsallow) and evaluate simple compound shell commands per command.codex execpolicy checkon 0.154.0 reportsjj git remote listandgh repo view …asprompt.In Codex core, a
promptdecision underAskForApproval::NeverbecomesPROMPT_CONFLICT_REASON:approval required by policy, but AskForApproval is set to Never. Process creation never starts. Other file-inspection calls that do not match apromptrule can still succeed on Full Access, which matches the report.Auto works because
on-request+auto_reviewcan satisfy those rule prompts. Automatic review then approved the same batches (risk=low). GitHub still needed an escalated retry for network; that is sandbox/network, not this reject.Upstream, not a T3 wiring bug
openai/codex#41068 is the same hard reject on Codex Desktop Full Access (
never+danger-full-access) when a project/user rule saysprompt. Also related: openai/codex#26575 (rules still load underdanger-full-access), openai/codex#25312 (opposite:promptrules ignored under some unrestricted/granular settings).Codex approval docs say
neverdisables prompts, and automatic review only applies to interactive policies (on-requestor granular). Execpolicypromptrules still require an approval path.nevertherefore fails closed instead of running the command.#9506 is a different failure (managed MDM/requirements rejecting thread start) and was closed unmerged. No T3 duplicate found for this error.
Workaround
Switch the thread to Auto (verified in the original logs), or change the matching
~/.codex/rulesdecisions fromprompttoallowif those commands should run unattended. Better error wording alone would not make Full Access execute the rejected batches.Next step
Leave T3 Full Access mapped to Codex’s own Full Access preset. Track the Codex execpolicy /
neverconflict upstream. A T3-side remap (for example granularrules: true, oron-request+danger-full-access+auto_review) would be a product decision to diverge from Codex Desktop so prompt-rule commands are not dead-ended. That is out of scope for this triage.michft commentedon Sep 18, 2026
It is a more the UI is wrong thing. That the UI allows you to set "Full Access" and then doesn't change the underlying permissions or alert that upstream is still not full access, that is a failure of UI. That "Ask(User)ForApproval = prompt" does not propagate within FullAccess is not even partial access, it is default to block when unsure. Probably an expectation issue for me.
seankoji commentedon Oct 11, 2026
the combined effect with #11458 means that I cant start new sessions in opencode and chatgpt providers without one of them breaking