Warden: code-review

[github-actions]

Warden Scheduled Scan Results

Run: 2026-07-20T07:18:39.308Z
Commit: 60cfdc3

Summary

Severity	Count
Medium	3
Low	2

Findings

src/mcp/tools/macos/stop_mac_app.ts

• BHS-GHQ pkill -f with unvalidated appName may kill unintended processes (L68) · medium
  pkill -f matches the given pattern as a regex against the full command line of every process. Passing an arbitrary user-supplied appName here can match and terminate unrelated processes (e.g., a short/common name, or regex metacharacters), and could be abused to kill processes the caller shouldn't be able to target. Consider using pkill -x against the executable name, resolving the app to a specific PID first, or at least validating/escaping appName.
• ALJ-4DM processId === 0 produces misleading log target (L60) · low
  On line 63, params.processId ? \PID ${params.processId}` : params.appName!uses a truthy check, which is inconsistent with the!== undefinedchecks on lines 59 and 68. IfprocessId === 0(andappNameis undefined),targetbecomesundefinedand the log message readsStopping macOS app: undefined. Note: the executed command is not affected because line 68 correctly uses !== undefinedand would run['kill', '0']. Consider params.processId !== undefined` here for consistency. (PID 0 is not a normal target but the schema allows any number.)

src/utils/axe-helpers.ts

• 8W7-VQJ resolveAxePathFromSourceConfig throws, preventing fallback to bundled/PATH (L68-L82) · medium
  When axeSourcePath is configured but no release build exists (or the directory is missing), this throws instead of returning null. That aborts resolveAxeBinary() entirely, so bundled and PATH fallbacks are never tried, and callers like areAxeToolsAvailable()/getAxePath() (documented to return null) will raise instead. Consider returning null (or logging a warning) on missing builds so resolution can continue.

src/utils/renderers/domain-result-text.ts

• 6ST-WJ2 activeProfile may be undefined, causing crash in Set Defaults path (L1128-L1131) · medium
  activeProfile is looked up via a chain that can resolve to undefined (empty profiles map), but the final "set" branch dereferences activeProfile[key] without optional chaining, which will throw at runtime.

src/utils/bundle-id.ts

• 737-7ZE Bundle ID helper returns untrimmed output, relying on callers to trim (L11) · low
  runSpawn in src/utils/bundle-id.ts returns result.output || '' without trimming. Both defaults read ... CFBundleIdentifier and /usr/libexec/PlistBuddy -c 'Print :...' terminate output with a trailing newline, so extractBundleIdFromAppPath returns a bundle ID like com.example.app\n. All three current callers (build_run_sim.ts:425, build_run_device.ts:177, get_app_bundle_id.ts via bundleId.trim()) work around this by calling .trim() on the result, which mitigates immediate breakage but is fragile: any future caller that forgets to trim will pass a newline-terminated bundle ID into downstream operations (launch, install, comparisons). Trimming inside the helper would eliminate the trap and simplify callers.

---

Generated by Warden

[sentry-pierre]

I spot-checked the reported findings against 60cfdc3. All four code paths match the description.

• stop_mac_app.ts:68 passes raw params.appName into pkill -f.
• stop_mac_app.ts:63 uses a truthy check that skips processId === 0.
• axe-helpers.ts:82 throws instead of returning null when the configured source directory is missing or has no release build.
• domain-result-text.ts:1131 dereferences activeProfile[key] without guarding for undefined.
• bundle-id.ts returns untrimmed spawn output, leaving a trailing newline for callers to handle.

Consider splitting these into individual issues so they can be assigned and closed independently.