Quote mapper-generated validation command arguments

[rohitjavvadi]

Problem

Some mapper-generated validation commands interpolate repo-controlled paths, package names, task names, or test paths directly into shell command strings. Those commands are later executed through the validation path with shell: true, so a project path or package name containing shell metacharacters can be interpreted as command syntax instead of a literal argument.

Evidence

Examples on current main:

• src/mappers/projects.ts:204 builds pnpm --dir ${packageRoot} ${script}.
• src/mappers/projects.ts:212 builds npm --prefix ${packageRoot} run ${script}.
• src/mappers/shared.ts:369 and src/mappers/shared.ts:377 do the same for shared Node script commands.
• src/mappers/turbo.ts:129-137 interpolates Turbo task/filter values directly.
• src/mappers/rust.ts:92 interpolates a crate member path into cargo test --manifest-path.
• src/mappers/swift.ts:177 and src/mappers/swift.ts:217 interpolate nested Swift package roots into swift test --package-path.
• src/mappers/elixir.ts:304 interpolates a test path into mix test.
• src/app.ts:1076-1078 runs feature validation commands after fix.
• src/exec.ts:20-28 executes command strings with shell: true.

Reproduction idea

A workspace package under a path such as:

apps/web; touch INJECTED

can produce a validation command shaped like:

pnpm --dir apps/web; touch INJECTED test

When that string is executed by a shell, touch INJECTED is no longer just part of the package path. The same class of issue can happen with Turbo filters/package names and other mapper-generated command arguments.

Expected behavior

Mapper-generated validation commands should treat repo-derived paths, task names, package names, and test paths as literal command arguments. A weird but valid path should either be safely quoted or rejected before it reaches shell execution.

Possible fix

Use the existing shell quoting helper for dynamic command arguments before assembling validation command strings. At minimum this should cover Node package roots/scripts, Turbo task/filter values, Rust manifest paths, Swift package roots, and Elixir test paths.

Regression coverage should include:

• package roots containing ;
• package names or filters containing ;
• paths containing command substitution syntax such as $()
• existing simple command output staying unchanged

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Latest ClawSweeper review: 2026-05-24 06:58 UTC / May 24, 2026, 2:58 AM ET.

Workflow note: Future ClawSweeper reviews update this same comment in place.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Summary
Keep open: current main still builds several mapper-generated validation commands by interpolating repo-derived paths, task names, filters, or test paths into strings that are later executed with shell: true, so the reported command-injection class remains actionable.

Reproducibility: yes. Source inspection gives a high-confidence path: a workspace package root like apps/web; touch INJECTED can produce an unquoted validation command, and runCommand executes that string with shell: true; I did not execute it because this review is read-only.

Next step
No automated repair lane is selected because this is security-sensitive command construction work that should be explicitly owned or promoted by maintainers.

Security
Needs attention: Needs attention because mapper-generated validation commands can turn repo-controlled paths or names into shell syntax during validation.

Review details

Best possible solution:

Quote every dynamic mapper-generated command argument with the existing helper, or move validation commands to an args-based execution model, and add regression tests for semicolons and command substitution while preserving simple command output.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection gives a high-confidence path: a workspace package root like apps/web; touch INJECTED can produce an unquoted validation command, and runCommand executes that string with shell: true; I did not execute it because this review is read-only.

Is this the best way to solve the issue?

Yes. Reusing shellQuotePath for every repo-derived command argument is the narrowest maintainable repair; rejecting unusual paths is a fallback, but would be less compatible than literal argument quoting.

Label changes:

• add P1: The issue describes a command-injection path in post-fix validation where repo-controlled names or paths can become shell syntax.
• add impact:security: The affected behavior crosses a command-execution security boundary by passing unquoted repo-derived arguments to shell: true.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P1: The issue describes a command-injection path in post-fix validation where repo-controlled names or paths can become shell syntax.
• impact:security: The affected behavior crosses a command-execution security boundary by passing unquoted repo-derived arguments to shell: true.

Security concerns:

• [high] Quote mapper-generated validation arguments — src/mappers/projects.ts:204
  Several mappers build validation command strings with unquoted repo-derived values, and the validation executor runs those strings through a shell, allowing metacharacters in paths or names to change command structure.
  Confidence: 0.91

What I checked:

• Node workspace command interpolation: scriptCommand still returns package-local commands such as pnpm --dir ${packageRoot} ${script} and npm --prefix ${packageRoot} run ${script} without quoting the dynamic package root or script token. (src/mappers/projects.ts:196, 857d854ac8d0)
• Shared Node command interpolation: nodeScriptCommand repeats the same unquoted package-root and script interpolation for shared mapper-generated validation commands. (src/mappers/shared.ts:357, 857d854ac8d0)
• Turbo command interpolation: turboCommand interpolates the dynamic task and filter directly into turbo run command strings. (src/mappers/turbo.ts:127, 857d854ac8d0)
• Other mapper path interpolation: Rust, Swift, and Elixir mapper paths are also inserted into validation command strings without quoting, including cargo test --manifest-path ${member}/Cargo.toml, swift test --package-path ${packageRoot}, and mix test ${path}. (src/mappers/rust.ts:92, 857d854ac8d0)
• Validation executes through a shell: fix validation collects feature validation commands and passes each command string to runCommand; runCommandRaw then spawns the command with shell: true. (src/exec.ts:20, 857d854ac8d0)
• Existing quoting helper is available: shellQuotePath already implements platform-sensitive quoting for paths, and current tests cover POSIX metacharacter escaping for the helper but not the affected mapper command builders. (src/shell.ts:1, 857d854ac8d0)

Likely related people:

• Peter Steinberger: Blame for the affected mapper command builders and shell execution path points to the v0.4.0 release snapshot authored by Peter, and shortlog over the central paths shows Peter as the visible current-history author. (role: current implementation provenance; confidence: high; commits: cdd58ac59213; files: src/mappers/projects.ts, src/mappers/shared.ts, src/mappers/turbo.ts)
• Simon Guldager: Commit 5ab0460 added src/shell.ts, src/shell.test.ts, and .NET mapper quoting coverage, which is the existing helper pattern the issue proposes reusing. (role: adjacent quoting helper contributor; confidence: medium; commits: 5ab0460274dd; files: src/shell.ts, src/shell.test.ts, src/mappers/dotnet.ts)

Remaining risk / open question:

• A partial mapper-only fix could miss another validation command builder that still passes repo-derived text into the shared shell execution path.
• Cross-platform quoting needs care because shellQuotePath has different POSIX and Windows behavior and current affected mapper tests only cover simple command strings.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 857d854ac8d0.