What version of the Codex App are you using (From “About Codex” dialog)?
26.429.30905
What subscription do you have?
Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
- Project-attached automations can silently stall before prompt delivery.
When an automation is attached to a trusted project folder, Codex Desktop creates a thread, but the automation prompt is not delivered to the model. The run shows no assistant response.
Local state shows the failed automation-created thread with this pattern:
cwd: C:\Path\To\TrustedProject
sandbox_policy: {"type":"read-only"}
approval_mode: on-request
first_user_message: ""
tokens_used: 0
model: null
reasoning_effort: null
Expected behavior: the automation should start in the selected trusted project folder, receive the automation prompt, load its configured model/reasoning effort, and produce either an assistant response or an explicit failure message.
Actual behavior: the thread is created but appears to stall before prompt injection. There is no response because the model seems never to receive the automation prompt.
- Some automation runs use a read-only sandbox despite full-access global configuration.
My global Codex config is:
sandbox_mode = "danger-full-access"
approval_policy = "never"
[windows]
sandbox = "elevated"
However, some automation-created threads that do receive the prompt still show:
sandbox_policy: {"type":"read-only"}
approval_mode: never
first_user_message: "Automation: <automation title>..."
tokens_used: >0
model: <configured model>
reasoning_effort: <configured reasoning effort>
This causes local actions that need filesystem or process access to fail, even though normal interactive Codex chats use the expected full-access configuration.
Clarification: this does not appear to affect normal manually-created chats in the same trusted project folder. Normal chats receive the user message, load the model, respond normally, and use the expected full-access configuration. The issue appears specific to automation-created threads.
Workaround: setting the automation to projectless / Chats mode avoids the project-attached silent stall:
But this is only a workaround, and the automation can still be affected by unexpected read-only sandbox behavior in some runs.
What steps can reproduce the bug?
- Configure Codex Desktop on Windows with full-access local execution:
sandbox_mode = "danger-full-access"
approval_policy = "never"
[windows]
sandbox = "elevated"
-
Create or edit a recurring Codex Desktop automation with a normal prompt and model/reasoning settings.
-
Attach the automation to a trusted project folder:
cwds = ["C:\\Path\\To\\TrustedProject"]
-
Trigger the automation or wait for its scheduled run.
-
Observe that Codex Desktop creates a thread, but the automation does not respond.
The failed automation-created thread had this pattern in local state:
session/thread id: <redacted>
cwd: C:\Path\To\TrustedProject
sandbox_policy: {"type":"read-only"}
approval_mode: on-request
first_user_message: ""
tokens_used: 0
model: null
reasoning_effort: null
This suggests the failure happens before the automation prompt is injected into the thread. Token usage was 0, so there was no meaningful context window usage.
A separate but related reproduction is:
- Keep the same full-access global config.
- Run an automation that needs filesystem or process access.
- Observe that some automation-created runs receive the prompt, but the thread still starts read-only:
session/thread id: <redacted>
sandbox_policy: {"type":"read-only"}
approval_mode: never
first_user_message: "Automation: <automation title>..."
tokens_used: >0
model: <configured model>
reasoning_effort: <configured reasoning effort>
In this second case, the prompt is delivered and token usage is nonzero, but the automation cannot reliably perform local full-access actions because the sandbox policy is unexpectedly read-only.
Normal manually-created chats in the same trusted project folder do not reproduce the issue. They receive the user message, load the model, respond normally, and use the expected full-access configuration.
What is the expected behavior?
The expected behavior is that Codex Desktop automations should start reliably with the same effective access policy shown in their configuration.
For a project-attached automation:
- Codex should create the automation thread in the trusted project folder.
- The automation prompt should be injected into the thread.
- The configured model and reasoning effort should be applied.
- The run should produce either an assistant response or an explicit startup/error message.
- The thread should not be created with an empty
first_user_message, tokens_used: 0, and model: null.
For a full-access automation:
- If global config is
sandbox_mode = "danger-full-access" and approval_policy = "never", the automation run should respect that policy unless a different automation-specific policy is clearly configured.
- Local filesystem/process actions should not fail because the automation silently started in
read-only mode.
- If automations intentionally use a different sandbox policy than normal chats, that should be visible in the UI/config and explained in the run output.
Normal interactive chats in the same trusted project folder already behave this way, so I would expect automation-created threads to initialize consistently too.
Additional information
This appears specific to automation-created threads, not normal interactive chats. Normal chats in the same trusted project folder receive the user message, load the model, respond normally, and use the expected full-access configuration.
There are two distinct failure modes:
-
Project-attached automation thread is created, but the prompt is never injected. Local state shows first_user_message: "", tokens_used: 0, model: null, and reasoning_effort: null.
-
Automation prompt is injected and the model starts, but the run uses sandbox_policy: {"type":"read-only"} despite global config being sandbox_mode = "danger-full-access" and approval_policy = "never".
The current workaround is to keep affected automations in projectless / Chats mode with cwds = ["~"], but that is still an automation-created thread, not a manually-created chat. This avoids the project-attached silent stall, but it does not fully explain or fix the unexpected read-only sandbox behavior.
The issue is hard to diagnose from the UI because failed project-attached runs can appear to be stuck with no visible error, even though local state suggests the model never received the automation prompt.
What version of the Codex App are you using (From “About Codex” dialog)?
26.429.30905
What subscription do you have?
Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
When an automation is attached to a trusted project folder, Codex Desktop creates a thread, but the automation prompt is not delivered to the model. The run shows no assistant response.
Local state shows the failed automation-created thread with this pattern:
Expected behavior: the automation should start in the selected trusted project folder, receive the automation prompt, load its configured model/reasoning effort, and produce either an assistant response or an explicit failure message.
Actual behavior: the thread is created but appears to stall before prompt injection. There is no response because the model seems never to receive the automation prompt.
My global Codex config is:
However, some automation-created threads that do receive the prompt still show:
This causes local actions that need filesystem or process access to fail, even though normal interactive Codex chats use the expected full-access configuration.
Clarification: this does not appear to affect normal manually-created chats in the same trusted project folder. Normal chats receive the user message, load the model, respond normally, and use the expected full-access configuration. The issue appears specific to automation-created threads.
Workaround: setting the automation to projectless / Chats mode avoids the project-attached silent stall:
But this is only a workaround, and the automation can still be affected by unexpected read-only sandbox behavior in some runs.
What steps can reproduce the bug?
Create or edit a recurring Codex Desktop automation with a normal prompt and model/reasoning settings.
Attach the automation to a trusted project folder:
Trigger the automation or wait for its scheduled run.
Observe that Codex Desktop creates a thread, but the automation does not respond.
The failed automation-created thread had this pattern in local state:
This suggests the failure happens before the automation prompt is injected into the thread. Token usage was
0, so there was no meaningful context window usage.A separate but related reproduction is:
In this second case, the prompt is delivered and token usage is nonzero, but the automation cannot reliably perform local full-access actions because the sandbox policy is unexpectedly
read-only.Normal manually-created chats in the same trusted project folder do not reproduce the issue. They receive the user message, load the model, respond normally, and use the expected full-access configuration.
What is the expected behavior?
The expected behavior is that Codex Desktop automations should start reliably with the same effective access policy shown in their configuration.
For a project-attached automation:
first_user_message,tokens_used: 0, andmodel: null.For a full-access automation:
sandbox_mode = "danger-full-access"andapproval_policy = "never", the automation run should respect that policy unless a different automation-specific policy is clearly configured.read-onlymode.Normal interactive chats in the same trusted project folder already behave this way, so I would expect automation-created threads to initialize consistently too.
Additional information
This appears specific to automation-created threads, not normal interactive chats. Normal chats in the same trusted project folder receive the user message, load the model, respond normally, and use the expected full-access configuration.
There are two distinct failure modes:
Project-attached automation thread is created, but the prompt is never injected. Local state shows
first_user_message: "",tokens_used: 0,model: null, andreasoning_effort: null.Automation prompt is injected and the model starts, but the run uses
sandbox_policy: {"type":"read-only"}despite global config beingsandbox_mode = "danger-full-access"andapproval_policy = "never".The current workaround is to keep affected automations in projectless / Chats mode with
cwds = ["~"], but that is still an automation-created thread, not a manually-created chat. This avoids the project-attached silent stall, but it does not fully explain or fix the unexpected read-only sandbox behavior.The issue is hard to diagnose from the UI because failed project-attached runs can appear to be stuck with no visible error, even though local state suggests the model never received the automation prompt.