codex - 💡(How to fix) Fix Expose structured shell status in PostToolUse hook payloads

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

PostToolUse hooks for shell tools currently receive the canonical tool input and a response payload that represents command output, but they do not appear to receive structured process status such as exit code, terminating signal, process id, or whether the process was still running when output was returned.

Please expose structured shell status in the PostToolUse hook input for Bash/shell tool events.

Root Cause

Consumers that need to distinguish host-side process intervention from ordinary command failure currently have to infer from text output or query external state after every shell command. Examples include:

  • host thermal killswitches that terminate a top CPU process,
  • OOM or supervisor kills,
  • stalled interactive sessions that later resolve as killed,
  • retry controllers that should back off on SIGKILL instead of repeating the same workload.

Without structured status, a hook cannot cheaply say "only inspect external kill markers when this command exited 137 or was terminated by SIGKILL." The safer workaround is to run a lightweight external marker check after every Bash PostToolUse, then dedupe markers locally.

Fix Action

Fix / Workaround

Without structured status, a hook cannot cheaply say "only inspect external kill markers when this command exited 137 or was terminated by SIGKILL." The safer workaround is to run a lightweight external marker check after every Bash PostToolUse, then dedupe markers locally.

Current workaround

Code Example

{
  "toolResponse": "...",
  "processStatus": {
    "pid": 12345,
    "exitCode": 137,
    "signal": "SIGKILL",
    "timedOut": false,
    "running": false
  }
}
RAW_BUFFERClick to expand / collapse

Summary

PostToolUse hooks for shell tools currently receive the canonical tool input and a response payload that represents command output, but they do not appear to receive structured process status such as exit code, terminating signal, process id, or whether the process was still running when output was returned.

Please expose structured shell status in the PostToolUse hook input for Bash/shell tool events.

Why this matters

Consumers that need to distinguish host-side process intervention from ordinary command failure currently have to infer from text output or query external state after every shell command. Examples include:

  • host thermal killswitches that terminate a top CPU process,
  • OOM or supervisor kills,
  • stalled interactive sessions that later resolve as killed,
  • retry controllers that should back off on SIGKILL instead of repeating the same workload.

Without structured status, a hook cannot cheaply say "only inspect external kill markers when this command exited 137 or was terminated by SIGKILL." The safer workaround is to run a lightweight external marker check after every Bash PostToolUse, then dedupe markers locally.

Requested fields

For shell PostToolUse payloads, include fields along these lines:

{
  "toolResponse": "...",
  "processStatus": {
    "pid": 12345,
    "exitCode": 137,
    "signal": "SIGKILL",
    "timedOut": false,
    "running": false
  }
}

Exact naming is not important; the key need is a stable, structured way for hooks to identify process termination and correlate it with external audit markers.

Current workaround

A local command hook polls an external thermal-kill marker helper after Bash PostToolUse and on prompt/session boundaries. It stays passive and only injects context, but it has to check more often than necessary because the hook payload lacks shell status.

Related issues found before filing

  • #21753 is a broad hook parity umbrella and mentions that PostToolUse needs a complete contract / PostToolUseFailure, but it is not a focused request for shell exit status fields.
  • #16246 covered missing PostToolUse events for long-running / polled exec sessions, which is related lifecycle coverage but not this payload-shape request.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Expose structured shell status in PostToolUse hook payloads