Repository navigation
Agent cannot edit files using the sandbox when resuming a session #3947
Description
What version of the VS Code extension are you using?
0.4.12
Which IDE are you using?
VS Code
What platform is your computer?
Linux 6.16.7-zen1-1-zen x86_64 unknown
What steps can reproduce the bug?
- Start a coding session with GPT5 (any thinking variant) or GPT5-Codex (any variant).
- Close the editor, click the new chat button or click back to go to the session list
- Pick any existing historical session
- Agent resumes work, but whenever the agent tries to use apply_patch to edit files, it encounters the error
execution error: codex-linux-sandbox was required but not provided. Using workarounds like bash sed continue to work
What is the expected behavior?
The agent can resume a session and edit files properly.
What do you see instead?
Straight from the horse agent's mouth:
Thanks — I reproduced it. Here’s the exact error emitted by apply_patch:
execution error: codex-linux-sandbox was required but not provided
Context
Command: apply_patch targeting packages/ui/shared/src/theme.css
Change attempted: trivial comment text edit (no-op) to avoid risk
This is the same error I saw earlier when the session resumed.
Diagnosis
This isn’t a permissions/escalation issue (we’re writing inside the workspace and other commands run fine).
It’s a harness-side sandbox mismatch: the apply_patch tool expects a sandbox shim (“codex-linux-sandbox”) that isn’t in this resumed session, so the patch runner refuses to start.
Running with elevated permissions doesn’t help for apply_patch itself; escalation helps for child-process tools (vitest/playwright/gh), but apply_patch depends on the agent harness, not the OS.
Workaround (as discussed)
If it helps your bug report, here are the conditions that trigger it for me:
Resuming a session the next day
Running apply_patch with a valid diff envelope (*** Begin Patch … *** End Patch) on a tracked file
Same error for both small and large patches
Other shell commands work; child-process runners need escalation but succeed when allowed
Additional information
This has been happening for a while with different versions of the extension.
Activity
etraut-openai commentedon Nov 25, 2025
I think this has been fixed in more recent versions of the extension and CLI. If you're still seeing this with the most recent version, please let us know.