fix(core): track attached stdout fd redirects - #5317

Independently verified this one — it's a real permission-gate bypass and the fix is correct. 👍

Repro (by construction): the tokenizer splits only on unquoted whitespace, so echo hi 1>.qwen/settings.json tokenizes to ['echo', 'hi', '1>.qwen/settings.json'] — the 1>… stays a single fused token. It isn't === any spaced operator, so it falls to the combined-form branch, where main's regex /^(<<-?|>>|>|2>>|2>|&>>|&>|<)(.+)$/ matches nothing that starts with 1 → the redirect is dropped → the write to .qwen/settings.json never becomes a write_file op and skips the permission check. The spaced form 1> file was already caught (tok === '1>'), so this closes exactly that no-space asymmetry. The added 1>>|1> (longest-first ordering is right) routes op !== '<' to writeFiles, no other change needed. ✔

Optional follow-up (non-blocking, low priority): the regex still ignores arbitrary fds, so echo x 3>.qwen/settings.json truncates the file undetected. But fd ≥ 3 only truncates without writing content and is never typed by accident, so 1> was the case worth fixing — a general \d+> handler can be a separate cleanup if you think it's worth it.

LGTM to merge once you flip it out of draft. Thanks for the catch!

@qwen-code /triage

Maintainer verification — local build + before/after semantics harness

Verified PR head 22bf5c4 against origin/main (f5761ac) on macOS (Darwin arm64, Node v22.22.2). This touches the shell permission-analysis boundary (extractShellOperations feeds the write/read-permission gate), so beyond the unit suite I ran a before/after harness driving the real extractShellOperations / extractShellOperationsAcrossCommand over an adversarial command corpus.

1. Build / tests / typecheck / lint (PR code)

2. Before/after behavioral harness

✅ Intended fix — attached stdout-fd redirects are now tracked as writes (were silently missed before):

✅ No regressions — unchanged before↔after: spaced 1> file / 1>> file, attached >file / >>file, 2>file, 2>/dev/null (ignored), &>file, < file, plain echo hi.

3. One finding (non-blocking): fd-dup over-detection is extended to 1>&

The fix also makes fd-duplications on fd 1 match the redirect regex, and they fall through to a spurious write op:

This is pre-existing behavior, not introduced by this PR. Root cause is looksLikePath('&2') === true (it only rejects $-vars, flags, pure ints, braces, URLs — not &N fd-dups). The same quirk already exists on main for the other operators and is unchanged here:

• echo hi 2>&1 → write_file /repo/&1 (same before & after)
• echo hi >&2 → write_file /repo/&2 (same before & after)

So the PR extends an existing looksLikePath limitation from >& / 2>& to 1>&. The direction is safe for a permission gate — it's over-detection on a nonsensical path, never under-detection, so it can't let a real write slip past; worst case is a spurious permission consideration on a 1>&2 command.

Suggested follow-up (separate, optional): skip &-prefixed fd-dup targets (&1, &2, &-) in extractRedirects / looksLikePath so the new 1>& and the pre-existing 2>& / >& cases are all cleaned up together.

Verdict

The core fix is correct and closes a real under-detection gap — attached 1>file / 1>>file writes were invisible to the permission analyzer while the spaced forms were tracked, so a command could write to a sensitive path (e.g. 1>.qwen/settings.json) without the write being seen. Zero regressions; the absolute-vs-relative cwd-dependency handling is correct. The only side effect (fd-dup → spurious write) is pre-existing behavior extended in the safe direction. ✅ Safe to merge. The fd-dup over-detection is worth a small follow-up but is not a blocker.

_{Verified by maintainer @wenshao: local build + unit suite + a before/after harness running the real semantics functions from both origin/main and the PR head (22bf5c4) over a 20-command corpus.}