Goal continuation can resume with a different sandbox/approval profile after restart

Summary

When Codex Desktop restarts, updates, or resumes in the middle of an active long-running goal, the resumed turn can receive a different environment_context / permission profile than the previous turn. This can cause the agent to behave as if permissions changed mid-goal, attempt unnecessary escalation, or misdiagnose local tool failures as repo/task failures.

Environment

• Product: Codex Desktop
• OS: Windows
• Workspace type: local Unity project
• Goal mode: active persistent goal / goal continuation
• Date observed: 2026-06-15
• Exact Codex version: 26.609.41114

What happened

During an active goal, the session initially had an unrestricted profile:

sandbox_mode: danger-full-access
approval policy: never
filesystem: unrestricted

After Codex restarted/resumed the goal, the next injected environment context changed to a restricted profile with escalation rules:

sandbox_mode: workspace-write
filesystem: restricted
approval/escalation rules enabled

Immediately after that, ordinary local read-only commands such as rg and cm status failed with a Windows sandbox initialization error:

windows sandbox: helper_unknown_error: setup refresh had errors

The assistant then interpreted the resumed session as having a stricter sandbox and attempted escalation. Shortly after another interruption/restart, the environment context returned to the original unrestricted profile:

sandbox_mode: danger-full-access
approval policy: never
filesystem: unrestricted

Expected behavior

When a persistent goal is resumed after a Codex restart/update, the resumed session should preserve the same effective sandbox and approval policy as the pre-restart session, unless the user or app explicitly changes it.

If the environment must change, Codex should make that transition explicit and stable so the agent can reason correctly.

Actual behavior

The resumed goal received a different permission profile mid-goal. This created a misleading state where:

• the agent believed the sandbox had become stricter,
• local read-only commands failed due to sandbox setup,
• escalation was attempted even though the original and later restored policy was approval: never,
• progress was interrupted by environment mismatch rather than task logic.

Why this matters

Long-running goals depend on continuity. Permission-profile drift during goal continuation can cause:

• incorrect diagnosis of failures,
• unnecessary escalation requests,
• aborted or delayed repo work,
• inconsistent behavior across turns,
• user confusion because the agent reports a sandbox change that the user did not request.

Reproduction outline

1. Start Codex Desktop on Windows.
2. Open a local workspace.
3. Begin a long-running persistent goal.
4. Observe initial environment context using unrestricted/full-access permissions.
5. Let Codex restart/update.
6. Observe that the resumed turn may inject a different sandbox/approval profile.
7. Run local read-only commands such as rg or VCS status.
8. Commands may fail with sandbox setup errors, and the agent may attempt escalation.

Suggested investigation areas

• Persist the original sandbox/approval profile across goal-continuation resumes.
• Ensure restart/update rehydration does not replace the active thread’s permission profile with a default or managed profile.
• If permission profile changes are intentional, surface an explicit system event explaining the change.
• Improve Windows sandbox helper failure reporting so setup failures are distinguishable from repo/tool failures.
• Prevent escalation attempts when the latest effective policy is approval: never.

Notes

This is filed as a bug report per the repository contribution guidance, rather than as a pull request.