What happened?
resolveCdTargetCwd (packages/core/src/permissions/shell-semantics.ts) calls extractRedirects(words, cwd) and discards the result, so a compound command like
cd somedir > .qwen/settings.json
produces zero extracted operations while the shell truncates the redirect target. When the target matches a Write(...) deny rule, the permission layer never sees the write: the segment is classified as a plain cd, the walker moves on, and extractShellOperationsAcrossCommand returns [].
Verified on current main with a scratch vitest case: extractShellOperationsAcrossCommand('cd subdir > /protected/out.txt', '/repo') returns [].
This is the same "writes escaping deny rules" family as #12246, through a different hole: not a mis-attributed cwd but a dropped redirect. It was flagged during review of #12280 and is pre-existing there.
What did you expect to happen?
The redirect target of a cd segment should surface as a write operation (or the segment should be treated as unanalyzable and fail closed), so Write-deny rules fire on cd dir > <protected file>.
Client information
Analysis on current main (post #11765), macOS. Reproduced via the permission extractor directly, no client needed.
Anything else we need to know?
A fix could either keep the extractRedirects(words, cwd) result in resolveCdTargetCwd and emit it as an op, or mark the segment cwdUnknown plus emit the redirect. Happy to send a PR once the direction is confirmed; noting it separately since #12280 should stay scoped to its own fix.
What happened?
resolveCdTargetCwd(packages/core/src/permissions/shell-semantics.ts) callsextractRedirects(words, cwd)and discards the result, so a compound command likeproduces zero extracted operations while the shell truncates the redirect target. When the target matches a
Write(...)deny rule, the permission layer never sees the write: the segment is classified as a plaincd, the walker moves on, andextractShellOperationsAcrossCommandreturns[].Verified on current main with a scratch vitest case:
extractShellOperationsAcrossCommand('cd subdir > /protected/out.txt', '/repo')returns[].This is the same "writes escaping deny rules" family as #12246, through a different hole: not a mis-attributed cwd but a dropped redirect. It was flagged during review of #12280 and is pre-existing there.
What did you expect to happen?
The redirect target of a
cdsegment should surface as a write operation (or the segment should be treated as unanalyzable and fail closed), soWrite-deny rules fire oncd dir > <protected file>.Client information
Analysis on current main (post #11765), macOS. Reproduced via the permission extractor directly, no client needed.
Anything else we need to know?
A fix could either keep the
extractRedirects(words, cwd)result inresolveCdTargetCwdand emit it as an op, or mark the segment cwdUnknown plus emit the redirect. Happy to send a PR once the direction is confirmed; noting it separately since #12280 should stay scoped to its own fix.