Harden run-command: avoid shell: true on Windows and validate argument contents
- Dominant language
- TypeScript
- Stars
- 102
- Forks
- 25
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 22
Description
`handleRunCommand` spawns with `shell: process.platform === 'win32'` (`app/electron/runCmd.ts:433`, `:540`), and `validateCommandData` (`:781`) only type-checks `command`/`args` — it does not constrain their contents. On Windows this means argument values are subject to shell interpretation rather than being passed literally.
This applies to every `run-command` caller, not to any single feature. Consent and permission secrets gate *which* commands may run, but not the shape of their arguments.
### Suggested fix
- Invoke without a shell on Windows (resolve the executable path explicitly), and/or
- Validate argument contents where handlers construct arguments from structured input (e.g. against Azure naming grammars).
### Impact
Low — requires code execution in the renderer, which already permits `run-command` with an arbitrary command line. Filed as hardening / defence-in-depth.
Noted while reviewing #781; not introduced there.
Contributor guide
Research direction
Start in app/electron/runCmd.ts at handleRunCommand (lines 433 and 540) and validateCommandData (line 781), then trace every run-command caller. The change is done when Windows arguments are not subject to shell interpretation and structured argument values are appropriately constrained, with existing command execution behavior preserved.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- electron, typescript
- Domain
- desktop, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100