fix(hooks): pass the tool exit code to Runtime API tool_call_after

[Hmbown]

What

Hooks now get a shell command's real exit code, and how it ended, on both the TUI and Runtime API threads. That holds for failing commands as well as passing ones.

There were two causes:

1. Runtime API path passed no exit code. fire_runtime_tool_completion_hooks (crates/tui/src/runtime_threads.rs) called .with_tool_result(&text, success, None), so DEEPSEEK_TOOL_EXIT_CODE was never set on Runtime API threads.
2. A failing bash command lost its exit code on both surfaces. finish_contract_bash_result (crates/tui/src/tools/shell.rs) reports a nonzero exit, a timeout, or a kill as Err(ToolError::ExecutionFailed { message }). The exit_code/status metadata it builds went only on the success path, and the hook helper read metadata only from Ok results. So every failing command reached tool_call_after and on_error with no exit code.

Changes

• ToolError::ExecutionFailed gains metadata: Option<Value> (crates/tools/src/lib.rs), along with ToolError::execution_failed_with_metadata and ToolError::metadata(). execution_failed(..) is unchanged (None). Patterns that named { message } now say { message, .. }. The error's display text and the model-facing contract ("nonzero must be a failed tool call") are unchanged.
• bash's failure path attaches the same metadata a success carries (exit_code, status, duration_ms, …).
• A new HookContext::with_tool_outcome(&result) sets the text, success flag, exit code, and status from a settled call. The TUI (tui/tool_routing.rs) and Runtime API (runtime_threads.rs) completion hooks both use it now, so each drops its own copy of the text/success/exit-code derivation. reported_tool_exit_code reads metadata from an Ok result or an Err, and is private to hooks::executor.
• A new env var, DEEPSEEK_TOOL_STATUS: completed, failed, timed_out, killed, or running. It is set only when a shell tool recorded one of those statuses, and never passes through an arbitrary metadata string. A timed-out command has no exit code, and this is how a hook can tell it apart.
• docs/HOOKS.md, docs/zh_hans/HOOKS.md, and the CHANGELOG are updated. crates/tui/CHANGELOG.md is synced.
• The hooks module doc no longer says only the TUI fires hooks. docs/HOOKS.md already listed Runtime API threads.

Tests

Both paths run the real bash tool for exit 0, exit 1, exit 127 (a missing command), and a timeout. They assert what tool_call_after and on_error receive:

case	DEEPSEEK_TOOL_EXIT_CODE	DEEPSEEK_TOOL_STATUS	DEEPSEEK_TOOL_SUCCESS	on_error
exit 0	0	completed	true	no
exit 1	1	failed	false	yes, same values
exit 127	127	failed	false	yes, same values
timeout	unset	timed_out	false	yes, same values

• TUI: tui::tool_routing::tests::bash_completion_hooks_get_exit_code_and_status_for_failures (through handle_tool_call_complete).
• Runtime API: runtime_threads::tests::runtime_shell_completion_delivers_exit_code_and_status_to_hooks (through fire_runtime_tool_completion_hooks).
• reported_tool_exit_code_reads_only_real_metadata_codes now also covers an error carrying code 127, a timeout with a status but no code, and an unknown status string that is not passed through.
• The shell tests contract_bash_nonzero_is_an_error_with_status_after_output and lowercase_bash_timeout_uses_seconds_and_fails now assert that the error carries exit_code/status.

Results:

• The focused codewhale-tui --lib run for the hook, shell, and tool_routing filters: 52 passed, 0 failed. The hooks::, tool_routing::, error_taxonomy, and protocol_parity run: 224 passed, 0 failed. codewhale-tools: 29 passed, 0 failed.
• Negative control: without the metadata on the error, both new tests and the 2 updated shell tests fail (4 failed). The hooks saw call-exit-1 unset unset false.
• Gates: cargo fmt --check is clean. Clippy (-p codewhale-tools -p codewhale-tui --all-targets --all-features, CI flags) is clean. These all pass: sync-changelog --check, check-versions --range-audit-advisory, contributor credit, the cheap Lint scripts, the web derive scripts, and vitest lib/public-copy.test.ts (6 passed). The persistence-backlog and runtime-contract measurement budgets were not run locally; CI runs them.

Refs #6582. The structured receipt feature requested there stays open.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-26T19:04:13.666332Z	a1db242	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.