Skip to content

Full Access rejects repository inspection commands that Auto permits #12248

Description

@michft

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.

Activity

  1. juliusmarminge commented on Sep 17, 2026

    @juliusmarminge
    Member

    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 execpolicy prompt rule, because never cannot ask. This is the same conflict Codex Desktop hits.

    What T3 is doing

    runtimeModeToThreadConfig maps:

    T3 mode approvalPolicy sandbox reviewer
    Full Access never danger-full-access user
    Auto on-request workspace-write auto_review

    Those values are applied on thread/start, thread/resume, and every turn/start. The retained rollout matches that mapping (11:57:58 Full Access, 12:35:30 Auto). 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.rules includes prefix_rule entries with decision = "prompt" for gh … repo and jj git … remote. Codex rules take the most restrictive matching decision (prompt beats allow) and evaluate simple compound shell commands per command. codex execpolicy check on 0.154.0 reports jj git remote list and gh repo view … as prompt.

    In Codex core, a prompt decision under AskForApproval::Never becomes PROMPT_CONFLICT_REASON: approval required by policy, but AskForApproval is set to Never. Process creation never starts. Other file-inspection calls that do not match a prompt rule can still succeed on Full Access, which matches the report.

    Auto works because on-request + auto_review can 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 says prompt. Also related: openai/codex#26575 (rules still load under danger-full-access), openai/codex#25312 (opposite: prompt rules ignored under some unrestricted/granular settings).

    Codex approval docs say never disables prompts, and automatic review only applies to interactive policies (on-request or granular). Execpolicy prompt rules still require an approval path. never therefore 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/rules decisions from prompt to allow if 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 / never conflict upstream. A T3-side remap (for example granular rules: true, or on-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.

  2. michft commented on Sep 18, 2026

    @michft
    Author

    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.

  3. seankoji commented on Oct 11, 2026

    @seankoji

    the combined effect with #11458 means that I cant start new sessions in opencode and chatgpt providers without one of them breaking

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.upstreamvia-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions