Repository navigation
PowerShell hashtable string value falsely parsed as blocked init command #834
Description
Summary
Desktop Commander 0.2.50 rejects a PowerShell start_process request with Command not allowed (outer error code INVALID_ARGUMENT) before the command runs. The blocked token init originates from a descriptive string value inside a PowerShell hashtable, not from an executable command.
This is related to #731, but distinct from that issue's PowerShell here-string / format case and the proposed here-string fix in #792.
Environment
- Desktop Commander v0.2.50 (remote
start_process) - Windows / Windows PowerShell (
powershell.exe) - Existing
blockedCommandscontainsinit; it was not modified.
Privacy-sanitized minimal reproduction
The following snippet is illustrative PowerShell input, not executed during preparation of this issue:
$metadata = [ordered]@{ Stage='preflight'; Operation='Device init then read-only health check' }; $metadata | ConvertTo-JsonWith the installed v0.2.50 dist/command-manager.js extraction logic, an in-memory, parser-only reproduction returns:
extractCommands(...) -> ["=", "init", "convertto-json"]
blocked match -> "init"
The same snippet with the literal Device preparation then read-only health check yields no init match. A genuine executable init remains detectable as init. None of these reproduced strings were executed as shell commands.
Evidence from the actual observed failure
The actual blocked request was a longer, private PowerShell automation command that included an [ordered]@{ ...; Operation='...' } logging field. start_process returned Command not allowed / INVALID_ARGUMENT immediately, before the requested process was started. Read-only inspection of the installed dist/tools/improved-process-tools.js showed it calls commandManager.validateCommand before terminalManager.executeCommand.
A local parser-only analysis of the preserved, private request isolated the same false-positive blocked token init. The complete original request and device/project paths are intentionally not shared.
Suspected parsing mechanism
In the v0.2.50 extractCommands implementation, the semicolon between PowerShell hashtable properties is treated as a command separator. extractBaseCommand then applies /\\w+=\\S+\\s*/g to a segment beginning with Operation='Device init ...', removing Operation='Device and incorrectly treating the next word init as the executable command.
This diagnosis is based on code inspection and in-memory parser replay, not on a patched runtime or a claim that every later permission gate would succeed.
Expected behavior
- Hashtable property delimiters and literal, non-executed string content must not become shell commands.
- Actually executable blocked commands (including nested/chained commands) must remain blocked.
- Command substitutions in expandable PowerShell contexts must still be checked where execution is possible.
- A parser regression test should demonstrate the false positive above is fixed and real
initinvocations are still rejected.
Requested resolution
Please provide a shell-aware command parser correction or a formally supported narrowly scoped approval mechanism. We do not request disabling the blocklist or workarounds through alternate execution tools.
Scope: This public report deliberately excludes all private paths, project names, device identities, firmware images, and logs.
Activity
xyyxyyxx commentedon Oct 11, 2026
Follow-up for a supported admission path, without changing the installed safety blocklist or rerouting a rejected command:
src/command-manager.tsstill tokenizes semicolons within PowerShell hashtables as shell command separators.Operation='Device init then read-only health check'is treated as literal data; (2) a genuinely executable blockedinitis still denied; (3) chained and nested executable blocked commands remain denied; (4) PowerShell expandable$()contexts remain checked; (5) no relaxation ofblockedCommands.No local parser, safety configuration, runtime or permission bypass has been performed. We will keep the affected command blocked until the official correction is verified.
xyyxyyxx commentedon Oct 15, 2026
2026-10-15 follow-up: requesting maintainer triage and the supported resolution/admission procedure for this existing issue.
We have preserved a further remote
start_processrejection observed on 2026-10-14 (Command not allowed, outerINVALID_ARGUMENT, no PID). The complete rejected request includes a subsequent hardware workflow, not only JSON logging; it has not been resubmitted, rewritten or rerouted.Existing parser-only evidence for the preserved request shows a quoted hashtable value such as
scope='Device init <=1; read-only diagnostics'being reduced to an executable-lookinginittoken by assignment removal. This is offline reproduction, not an admission-server audit of the actual matched rule. Cached 0.2.50 and 0.2.51 classifier files had identical SHA-256; this does not establish the currently deployed server version. Our isolated proposal remains NOT DEPLOYABLE and has not been installed. No new parser investigation is requested here.Could a maintainer provide:
Our application correction is frozen separately. Any later changed application/source/electrical scope will need its own applicable review; it is not a renamed bypass of the original rejection. A successful unrelated command, issue closure, local mock test or generic user authorization will not be treated as admission.
Private originals and existing reproducer materials are retained locally for a maintainer-designated secure channel. No device identifiers, private paths, credentials, firmware or full hardware launch command are included in this public follow-up.
fix(command-manager): do not turn quoted hashtable values into commands