Desktop automations can start in workspace-write and switch to danger-full-access after chat interaction

What version of Codex is running?

Codex Desktop / VS Code-backed local app flow

Observed locally in session metadata with cli_version 0.115.0-alpha.4.

Which model were you using?

gpt-5.4 and previously gpt-5.3-codex in automation runs

What platform is your computer?

Windows 11

What steps can reproduce the bug?

1. Configure Codex Desktop with global full access enabled.
2. In local state, confirm the app is in full access mode. In my case .codex-global-state.json contains:

• "agent-mode":"full-access"
• "skip-full-access-confirm":true

1. Create a recurring automation that needs Git access (git pull, branch creation, commit, PR) and runs in a local workspace.
2. Let the automation start on its own from the scheduler/background runner.
3. Inspect the generated rollout JSONL and/or local threads state.
4. Then interact with the automation thread in the chat UI after it has already started.

What is the expected behavior?

If the app is configured for full access, a Git-capable automation should start with the same effective sandbox policy from the beginning.

A scheduled automation should not require a user to enter the chat before it can use the intended permission level.

What do you see instead?

Some automation runs start as background threads with:

• sandbox_policy.type = "workspace-write"
• network_access = false

This causes failures in normal Git automation steps such as writing .git/FETCH_HEAD or creating branch lockfiles under .git/refs/heads.

After the thread is interrupted/re-entered via the chat UI, the same thread/session can then receive danger-full-access permissions and the Git commands start working.

This makes scheduled automations unreliable and appear to "fix themselves" only after manual user interaction.

Additional information

I found strong local evidence that the sandbox differs between the automatic/background creation path and the later interactive chat path.

Evidence from local state/logs:

1. Global app state already indicates full access:

• .codex-global-state.json includes agent-mode = full-access
• .codex-global-state.json includes skip-full-access-confirm = true

1. A scheduled automation run started with restricted sandbox in its first turn context:

• rollout file: rollout-2026-03-12T20-52-02-019ce476-e43e-7de1-bdb6-9db0d759c68f.jsonl
• first turn_context shows sandbox_policy.type = workspace-write
• same turn context shows network_access = false

1. Later in the same conversation history, after turn_aborted / re-entry through the chat UI, new developer permissions were injected with danger-full-access.

1. The local threads table in state_5.sqlite shows mixed sandbox policies for the same automation title:

• several runs recorded as {"type":"danger-full-access"}
• some runs recorded as {"type":"workspace-write", ... "network_access":false}

This suggests the automation scheduler/background runner may sometimes ignore or fail to inherit the current interactive full-access mode.

Related but not identical:

• There are other issues about inconsistent sandbox/approval behavior in the extension/app, but this report is specifically about scheduled automations starting with a different sandbox than the app's configured full-access mode, then effectively recovering only after user interaction.

Impact:

• breaks unattended Git automations
• causes false Permission denied failures on .git
• forces manual intervention in workflows that should be autonomous

If helpful, I can provide a sanitized excerpt of the rollout JSONL showing the initial workspace-write turn context and the later danger-full-access developer instructions in the same conversation history.