VS Code goal continuation starts with managed workspace-write sandbox instead of configured full access

Summary

In the VS Code Codex integration, a thread that is configured for full access starts normal interactive turns with the expected permissions, but /goal continuation turns start with a managed workspace-write sandbox and on-request approvals.

This appears to be the same class of sandbox propagation issue as #15310, but triggered by Goal mode / active goal continuation rather than desktop scheduled automations.

Environment

• IDE: VS Code
• Platform: Windows
• Model: gpt-5.5
• Global/local expected mode: full access / no approvals
• Relevant config observed locally:
• model = "gpt-5.5"
• model_reasoning_effort = "xhigh"
• [windows] sandbox = "elevated"
• features.goals = true

Expected behavior

After starting or resuming a /goal in a VS Code thread, the turn should use the same effective permissions as ordinary interactive chat turns when the user has configured full access:

approval_policy = never
sandbox_policy.type = danger-full-access
permission_profile.type = disabled

Git operations such as git add and git commit should not request additional approval solely because the turn is a goal continuation.

Actual behavior

The same thread started ordinary turns with:

approval_policy = never
sandbox_policy.type = danger-full-access
permission_profile.type = disabled

But when Goal mode continued work, the next turn was started with:

approval_policy = on-request
sandbox_policy.type = workspace-write
permission_profile.type = managed
sandbox_policy.network_access = false

The injected user payload for the turn was:

<goal_context>
Continue working toward the active thread goal.
...
</goal_context>

This caused routine git writes to fail and then request escalation. Example failure from the same thread:

fatal: Unable to create 'C:/WB_AUTOPILOT_V2/.git/index.lock': Permission denied

The agent then retried commands with approval escalation, even though ordinary interactive turns in the same environment were full access.

Local timeline evidence

From the affected thread JSONL:

2026-05-24T06:48:23Z turn_context:
approval_policy=never
sandbox_policy.type=danger-full-access
permission_profile.type=disabled

2026-05-24T07:07:38Z task_started
2026-05-24T07:07:38Z developer permissions injected workspace-write/on-request
2026-05-24T07:07:38Z turn_context:
approval_policy=on-request
sandbox_policy.type=workspace-write
permission_profile.type=managed

2026-05-24T07:07:38Z user payload:
<goal_context> Continue working toward the active thread goal ... </goal_context>

After cancelling the old goal, restarting VS Code, and explicitly creating a new goal, the new goal continuation still started with the same restricted context:

2026-05-24T10:02:34Z task_started
approval_policy=on-request
sandbox_policy.type=workspace-write
permission_profile.type=managed
network_access=false

<goal_context>
Continue working toward the active thread goal.
</goal_context>

So this is not caused by a stale old goal, and not caused by subagents. A subagent spawned from the affected parent also used the restricted profile, but the parent thread itself had already switched to managed workspace-write.

Impact

• Goal mode becomes much less useful for trusted local automation on Windows/VS Code.
• Git operations fail or prompt unexpectedly because .git writes are blocked.
• Network access is disabled in goal continuation even when the user expects full-access behavior.
• The behavior is confusing because ordinary interactive turns in the same thread/config can use danger-full-access, while goal continuation silently uses a different permission profile.

Related

• #15310 describes a very similar fallback for desktop automations: automation launches do not propagate the full-access sandbox override and fall back to workspace-write.
• This issue appears to be the Goal mode / VS Code continuation equivalent of that sandbox-policy propagation problem.