Harden tool terminal execution with command blocklisting and persistent shell process

[Copilot]

When PowerShell (and other shells) run in interactive mode with stdin piped rather than a real PTY, they echo commands written to stdin back to stdout. This caused the internal sentinel used for exit-code detection to appear verbatim in the terminal UI:

$__pptb_ok__ = $?; $__pptb_lec__ = $LASTEXITCODE; $__pptb__ = if ($null -ne $__pptb_lec__) { $__pptb_lec__ } elseif ($__pptb_ok__) { 0 } else { 1 }; [Console]::Error.WriteLine("PPTB_CMD_END_..._$__pptb__")

Changes

• handleStdoutChunk() — replaces the inline stdout handler. When a command is executing, stdout is line-buffered and lines matching the sentinel echo pattern are dropped before display. Pass-through is immediate when no command is in flight.

• isSentinelEchoLine() — per-shell predicate matching the echoed sentinel:

  • pwsh: $__pptb_ok__ = $?;
  • cmd: echo PPTB_CMD_END_
  • posix: __pptb__=$?;

• flushStdoutBuffer() — drains the line buffer (with the same filter) when a pending command resolves or fails, shared between resolvePendingCommand and failPendingCommand.

• Use a meaningful title for the pull request.

• Follow the guidelines from the CONTRIBUTING.md.

• Mention the bug or the feature number the PR will be targeting.

• Test the change in your own code. (Compile and run)

• Resolve all GH Copilot comments.

[Power-Maverick]

@copilot allow command "cd", "code","dotnet build" and any other noon-intrusive commands that does not compromise the security. Only maintain the list of blocked command everything else should be allowed

[Copilot]

@copilot allow command "cd", "code","dotnet build" and any other noon-intrusive commands that does not compromise the security. Only maintain the list of blocked command everything e...

Done in commit refactor: switch terminal security from allowlist to blocklist. The approach is now a blocklist instead of an allowlist:

Blocked (shell interpreters and privilege-escalation tools):

• Unix/macOS shells: bash, sh, zsh, fish, csh, ksh, dash, tcsh
• Windows shells: cmd, cmd.exe, powershell, powershell.exe, pwsh, pwsh.exe
• Privilege escalation: sudo, su, runas, doas, pkexec
• npm run/exec/start/… and npx --shell/-c (prevent arbitrary script pivot)

Allowed: everything else — cd, code, dotnet build, git, pac, npm install, npx, etc.

[Power-Maverick]

@copilot Work on the review comments

[Power-Maverick]

@copilot getting error when executing a regular commands Set-Location: A positional parameter cannot be found that accepts argument '&&'. - the command it is trying to execute is cd "/Users/xyz/PPTB_PCF_Test" && npm run build but due to parsing it gets converted into following command cd '/Users/xyz/PPTB_PCF_Test' '&&' 'npm' 'start' and hence the error

[Copilot]

@copilot getting error when executing a regular commands Set-Location: A positional parameter cannot be found that accepts argument '&&'. - the command it is trying to execute is `...

Fixed in the latest commit. The root cause was that buildShellCommandInput was reconstructing the command from tokenized+quoted arguments, causing && to become the quoted literal '&&' — a positional argument rather than a shell operator.

The fix:

• Raw command written to stdin: the validated command string is now passed verbatim to the persistent shell process so &&, ||, ;, and | are interpreted natively by the shell.
• Compound command validation: a new splitCompoundCommand() function splits on those unquoted operators and each segment's executable is individually checked against the blocklist (so ls && bash still gets blocked).
• Command substitution guard: $(...) and backtick substitution are now explicitly rejected to preserve the security that argument-quoting previously gave us.
• npm run unblocked: npm run build, npm run start, etc. are no longer in the blocklist — they are legitimate developer commands. npx --shell / npx -c remain blocked as those explicitly spawn a shell interpreter.

With this change cd "/Users/xyz/PPTB_PCF_Test" && npm run build executes correctly.

[github-actions]

Bundle Size Report 📦

Bundle	Size
Main Process	970.83 KB
Renderer JS	550.26 KB
Renderer CSS	96.82 KB
Total	1.58 MB

Bundle Analysis Reports

The detailed bundle analysis reports are available in the workflow artifacts:

• 📊 Main Process: stats-main.html
• 📊 Renderer Process: stats-renderer.html

Download the artifacts from the workflow run to view interactive visualizations.

---

Bundle size tracking is now active! This helps prevent bundle bloat.