Windows CLI 0.147.0 rejects apply_patch inside Git linked worktree as outside project
What version of Codex CLI is running?
0.147.0
What subscription do you have?
ChatGPT account
Which model were you using?
gpt-5.6-sol
What platform is your computer?
Windows 11 x64, native Windows execution
What terminal emulator and version are you using (if applicable)?
PowerShell 7.6.4
What issue are you seeing?
On native Windows, Codex CLI rejects an apply_patch target inside the active Git linked worktree as if it were outside the project:
patch rejected: writing outside of the project;
rejected by user approval settings
The target is a single relative filename directly below the effective workdir. The CLI header confirms:
workdir: C:\dev\worktrees\<linked-worktree>
approval: never
sandbox: workspace-write [workdir, /tmp, $TMPDIR]
The failure still occurs with all of the following applied together:
default_permissions=":workspace"project_root_markers=[]--cdset to the linked worktree--add-dirset to the same linked worktreeapply_patchusing a relative path--ignore-user-config--ephemeral- web search disabled
External verification confirms:
- process exit code:
0 - target file created:
False - content matched:
False - Git status during probe: clean
- cleanup needed:
False - final Git status: clean
RELATIVE_WORKSPACE_WRITE_VERIFIED: False
No repository content was modified.
This appears to be an incorrect project-boundary or path-canonicalization decision for a native Windows Git linked worktree.
The uploaded diagnostic thread is:
019fdf04-b7c1-71a3-8f63-29fa03b3011d
What steps can reproduce the bug?
- On native Windows 11, create or use a Git linked worktree:
``text``
C:\dev\worktrees\<linked-worktree>
Its .git entry is the normal worktree pointer file.
- Start Codex CLI 0.147.0 with the worktree explicitly authorized:
``powershell
codex.cmd
--model gpt-5.6-sol
--ask-for-approval never
--config 'default_permissions=":workspace"'
--config 'project_root_markers=[]'
--config 'web_search="disabled"'
--cd 'C:\dev\worktrees\<linked-worktree>'
--add-dir 'C:\dev\worktrees\<linked-worktree>'
exec
--ephemeral
--ignore-user-config
-
```
- Ask Codex to use only
apply_patchto create one file with a relative path at the worktree root:
``text``
codex-relative-write-probe-<random>.tmp
- Observe that
apply_patchis rejected before creating the file:
``text``
patch rejected: writing outside of the project;
rejected by user approval settings
- Verify externally that the target does not exist and
git status --porcelain=v1 --untracked-files=allremains empty.
What is the expected behavior?
A relative apply_patch target directly inside the effective workdir should be writable when:
- the effective sandbox is
workspace-write; - the worktree is selected with
--cd; - the same path is granted through
--add-dir; :workspacepermissions are active; andproject_root_markers=[]makes the current directory the project root.
Codex should create the file inside the linked worktree, or provide a precise diagnostic identifying the canonical path/root mismatch. It should not classify the target as outside the project.
Additional information
This is related to, but distinct from:
- #30712: Windows
apply_patchfailure caused by split writable roots and sandbox-wrapper setup. - #32880: Windows linked-worktree failures when writing Git metadata under the resolved
.git/worktreesdirectory.
In this report:
- the sandbox initializes successfully as
workspace-write; - the rejected target is an ordinary workspace file, not Git metadata;
- the patch path is relative;
- both
--cdand--add-dirpoint to the same linked worktree; and - the repository remains clean after the rejection.
The interactive feedback session also exposed an unrelated stale default model (gpt-5.3-codex) that is unsupported for ChatGPT authentication. That model error did not invalidate the uploaded diagnostic thread and is not the primary issue reported here.