Agent cannot edit files using the sandbox when resuming a session

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.