fix(terminal): tell model when command was aborted by the user

[umi008]

Related GitHub Issue

Closes: #833

Description

When the user clicked the Abort button on a running shell command, ExecaTerminalProcess emitted shell_execution_complete with { exitCode: 0 } regardless of whether the process completed normally or was killed by the user. The model received no indication that the user intervened — it would see either a successful exit or SIGKILL and could suspect Linux OOM-killer or other system events, leading to incorrect diagnosis and wrong follow-up actions.

Fix:

1. Added optional aborted field to ExitCodeDetails interface
2. ExecaTerminalProcess.run() emits { exitCode: 0, aborted: this.aborted } so the flag reflects whether abort() was called
3. formatExitStatus() checks aborted first and returns "Command was aborted by the user." — clear, unambiguous, and takes priority over exit code or signal info

Test Procedure

1. Start Zoo Code in any mode that can run terminal commands
2. Send a long-running command (e.g., sleep 60)
3. Click the Abort button in the UI while the command is running
4. Verify the model receives: Command executed in terminal... Command was aborted by the user.
5. Verify the model does NOT speculate about OOM-killer, SIGKILL, or other system events

Pre-Submission Checklist

• Issue Linked: Closes [BUG] Zoo Code does not tell model when command Abort button was pressed #833
• Scope: One focused fix — communicates user abort to the model
• Self-Review: Backward-compatible; aborted is optional so all existing callers work unchanged
• Testing: TypeScript compilation verified; abort path in ExecaTerminalProcess tested end-to-end
• Documentation Impact: No documentation updates required
• Contribution Guidelines: Read and agree

Screenshots / Videos

N/A — backend message formatting, no UI changes.

Documentation Updates

• No documentation updates are required.

Additional Notes

The VSCode terminal path (TerminalProcess) sends Ctrl+C instead of SIGKILL when aborting, which correctly produces SIGINT in the exit details — that path was not affected by this bug. The fix targets the execa-based fallback path specifically.

Summary by CodeRabbit

• Bug Fixes
  • Added clear messaging when a command is aborted by the user.
  • Improved command completion reporting to distinguish user-aborted runs from successful exits.
  • Preserved abort status details for more accurate command results.

[coderabbitai]

Warning

Review limit reached

@umi008, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 13 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: ac6c5786-8acd-4a72-8ee4-82f729a6a0ec

📥 Commits

Reviewing files that changed from the base of the PR and between 689894b and 5f21e21.

📒 Files selected for processing (1)

• src/integrations/terminal/__tests__/ExecaTerminalProcess.spec.ts

📝 Walkthrough

Walkthrough

Command abort state is added to terminal completion data, documented in exit details, and rendered as a dedicated “aborted by the user” message.

Changes

Command abort status

Layer / File(s)	Summary
Abort status contract and propagation src/integrations/terminal/types.ts, src/integrations/terminal/ExecaTerminalProcess.ts	ExitCodeDetails documents the optional aborted flag, and successful completion events include the process abort state.
Aborted status formatting src/core/tools/ExecuteCommandTool.ts	formatExitStatus() returns a dedicated message for user-aborted commands.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related issues

• #524 — Related to propagating user-aborted Execa command status through completion handling.
• #523 — Related to Execa terminal abort and command-completion status handling.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is concise and accurately summarizes the main change: reporting user-aborted terminal commands.
Description check	✅ Passed	The description includes the linked issue, implementation summary, test procedure, checklist, and notes required by the template.
Linked Issues check	✅ Passed	The changes satisfy issue #833 by explicitly marking aborted commands and prioritizing that status in the model-facing message.
Out of Scope Changes check	✅ Passed	The PR stays focused on terminal abort reporting and related type/message changes, with no obvious unrelated additions.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/integrations/terminal/ExecaTerminalProcess.ts (1)

134-144: 🎯 Functional Correctness | 🔴 Critical | 🏗️ Heavy lift

Error-path emissions are missing the aborted flag, causing a race condition that undermines the PR's objective.

When abort() sends SIGKILL, the subprocess stream can throw an ExecaError (with signal: "SIGKILL") before the for await loop at line 89 checks this.aborted. Execution then falls into the catch block, which emits shell_execution_complete without aborted: this.aborted. Downstream, formatExitStatus would then return "Process terminated by signal SIGKILL" — the exact ambiguous message this PR aims to eliminate.

Both error paths (lines 137 and 143) must propagate aborted: this.aborted so the abort flag survives regardless of which path executes.

🐛 Proposed fix: include `aborted` in error-path emissions

 		} catch (error) {
 			if (error instanceof ExecaError) {
 				console.error(`[ExecaTerminalProcess#run] shell execution error: ${error.message}`)
-				this.emit("shell_execution_complete", { exitCode: error.exitCode ?? 0, signalName: error.signal })
+				this.emit("shell_execution_complete", { exitCode: error.exitCode ?? 0, signalName: error.signal, aborted: this.aborted })
 			} else {
 				console.error(
 					`[ExecaTerminalProcess#run] shell execution error: ${error instanceof Error ? error.message : String(error)}`,
 				)
 
-				this.emit("shell_execution_complete", { exitCode: 1 })
+				this.emit("shell_execution_complete", { exitCode: 1, aborted: this.aborted })
 			}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/integrations/terminal/ExecaTerminalProcess.ts` around lines 134 - 144,
Include aborted: this.aborted in both shell_execution_complete payloads within
ExecaTerminalProcess#run’s catch block, covering both ExecaError and generic
error paths so abort state is propagated consistently.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@src/integrations/terminal/ExecaTerminalProcess.ts`:
- Around line 134-144: Include aborted: this.aborted in both
shell_execution_complete payloads within ExecaTerminalProcess#run’s catch block,
covering both ExecaError and generic error paths so abort state is propagated
consistently.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 2e181b82-ca9e-4335-bf62-b2f42ca6ec27

📥 Commits

Reviewing files that changed from the base of the PR and between 116b70e and 689894b.

📒 Files selected for processing (3)

• src/core/tools/ExecuteCommandTool.ts
• src/integrations/terminal/ExecaTerminalProcess.ts
• src/integrations/terminal/types.ts

[codecov]

Codecov Report

❌ Patch coverage is 33.33333% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/core/tools/ExecuteCommandTool.ts	0.00%	1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!