Repository navigation
fix(O148): analyze pwsh nested execution deeper; beyond the cap fails closed - #161
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f7674edaf3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const nested = scanCommand(inner, ctx, depth + 1); | ||
| resolved.push(...nested.resolved); | ||
| unresolved.push(...nested.unresolved); |
There was a problem hiding this comment.
Bound nested-command traversal as well as recursion depth
For deeply nested scriptblocks, extractNestedCommands() returns every descendant block, not just immediate children, so each recursive call scans descendants again and the depth cap does not bound the total work or accumulated results. After building, scanning '& { '.repeat(80) + 'Write-Host hi' + ' }'.repeat(80) took about eight seconds and produced 1,581,580 unresolved entries; 100 wrappers (only 613 characters) threw RangeError: Maximum call stack size exceeded at the spread into unresolved. Since findShellProtectedWrites() invokes this scanner synchronously, these inputs stall or abort protected-path checking instead of returning the intended fail-closed marker. Traverse only immediate nested bodies or enforce a shared work/result budget that stops scanning once exhausted.
Useful? React with 👍 / 👎.
O148 (P2): deep PowerShell nesting hid writes from the scanner
The pwsh write-target scanner documented its own gap: one-level nested
execution was analyzed, deeper nesting was silently ignored —
iex "& { Set-Content <moss config> x }"and& { & { & { & { … } } } }produced noresolved target, no unresolved marker and no gate hit.
Fix (
src/safety/pwsh-write-targets.ts)& { … }/. { … }/iexliterals /pwsh -c "…") arescanned recursively up to 3 levels (depth-capped, bounded).
Tests —
test/o148-pwsh-deep-nesting.spec.mjs(7)Depth-1 baseline, depth 2 and 3 resolve the real config target; depth-2
through
iexresolves; deeper-than-cap produces a gate hit (resolved targetor unresolved marker — never silence); deeply nested benign body fails
closed; one-level reads stay clean.
Revert-red (local, macOS)
Restoring the one-level guard → 7 red (incl. the
iexchain and both deepcases); with the fix 7/7. Related:
aa-o130-pwsh-write-targets153/153,aa-o130-dollar-control, o170 39/39.npm run checkgreen.Branch
fix/o148-pwsh-deep-nesting, base6b40504f.