Windows: all hook events silently fail because the consolidated `python3 -c` block exceeds the ~32KB CreateProcess arglist limit

[xannasavin]

Summary

On Windows (git-bash / msys2), every hook event silently fails because peon.sh passes ~30 KB of Python source to python3 -c "...". Windows' CreateProcess caps the full command line at ~32,767 characters, so the exec is rejected before Python ever runs. The failure is invisible because stderr on that line is redirected to /dev/null — peon debug status keeps reporting log files: 0, and no sounds play on Stop / Notification / PermissionRequest / etc.

Manual sub-commands (peon preview, packs list, volume) work fine because they take shorter code paths that don't go through the consolidated block.

Environment

• peon-ping: 2.17.3
• OS: Windows 11 Pro (build 26200)
• Shell: Git Bash / MSYS2
• Python: 3.12.x
• Installed via install.sh | bash to ~/.claude/hooks/peon-ping

Reproduction

With debug: true in config.json:

echo '{"hook_event_name":"Stop","session_id":"test","cwd":"/f/Git-Projects"}' \
  | bash ~/.claude/hooks/peon-ping/peon.sh

Expected: an entry in logs/peon-ping-<date>.log, a sound played via the msys2 backend.
Observed: silent exit, no log entries, no sound.

Temporarily removing the 2>/dev/null from line 4280 reveals the underlying error:

peon.sh: line 4280: .../python3: Argument list too long

peon debug status still shows log files: 0 no matter how many hook events fire.

Root cause

peon.sh lines ~3341–4280:

_PEON_PYOUT=$(python3 -c "
  <~30 KB of inline Python, with bash-interpolated $vars
   and the injected ${_PEON_STATE_PY_HELPERS} block>
" <<< "$INPUT" 2>/dev/null)

python3 -c "<code>" passes <code> as argv[2], which goes through Windows' CreateProcess command-line length limit. The consolidated block (added for the "~120–200 ms faster hook response" optimization) plus the interpolated state-helpers easily exceeds 32 KB.

Linux execve and macOS limits are ~2 MB, so this never surfaces there.

Local workaround (confirmed fix)

Write the Python to a temp file and invoke it by path; $INPUT still arrives via stdin:

_PEON_PY_TMP=$(mktemp -t peon-ping-XXXXXX.py 2>/dev/null || echo "/tmp/peon-ping-$$.py")
cat > "$_PEON_PY_TMP" <<__PEON_PY_EOF__
  <same Python block — unquoted heredoc preserves the same $/`/\ expansion
   that the current double-quoted `python3 -c "..."` already does,
   so the bash-interpolated variables still work unchanged>
__PEON_PY_EOF__
_PEON_PYOUT=$(python3 "$_PEON_PY_TMP" <<< "$INPUT" 2>/dev/null)
rm -f "$_PEON_PY_TMP"

After applying locally against v2.17.3, Stop / Notification / PermissionRequest events start logging and playing sounds immediately. Tested on Windows 11 + git-bash + Python 3.12.

Suggested upstream fix

Two reasonable approaches:

1. Temp file — what the workaround above uses. Small diff, preserves the existing bash-interpolation behavior the code already relies on, no Python rewrite needed.
2. python3 - — needs redesigning how $INPUT gets delivered (currently on stdin), so less clean.

Option 1 is the smaller change and matches the existing architecture. Happy to send a PR if helpful.

Secondary suggestion

Line 4280 unconditionally swallows stderr (2>/dev/null). Even a one-line message when debug: true or $PEON_DEBUG=1 would have made this obvious instead of an untraceable silent failure. Something like:

if [ "${PEON_DEBUG:-0}" = "1" ] || [ "$(jq -r .debug "$CONFIG")" = "true" ]; then
  _PEON_PYOUT=$(python3 ... <<< "$INPUT")
else
  _PEON_PYOUT=$(python3 ... <<< "$INPUT" 2>/dev/null)
fi

Worth considering as a general observability improvement — right now, any Python-side crash in that block on any platform will look identical to this Windows issue.

[lmagine]

Confirming this still reproduces on v2.22.0 (fresh install.sh | bash today) on Windows 11 + Git Bash + Python 3.14.3. The consolidated python block now measures 41,769 chars, well over the 32,767-char CreateProcess limit.

Repro on v2.22.0

After a fresh install, with debug: true:

INPUT='{"hook_event_name":"Notification","session_id":"test","message":"Claude needs your permission"}'
bash ~/.claude/hooks/peon-ping/peon.sh <<< "$INPUT"

• No output, exit 0
• logs/ remains empty — peon debug status shows log files: 0
• All real hook events (Stop, Notification, PermissionRequest, etc.) silently fail
• CLI paths (peon preview, packs list) work because they don't hit the consolidated block

Temporarily replacing the 2>/dev/null on the last line of the block (now line 5449) with 2>&1 reveals the real error:

peon.sh: line 5449: /c/Users/lmagi/AppData/Local/Python/bin/python3: Argument list too long

Workaround confirmed fixes v2.22.0

Applied the exact temp-file workaround from the original issue:

# was: _PEON_PYOUT=$(python3 -c "
_PEON_PY_TMP=$(mktemp 2>/dev/null || echo "${TMPDIR:-/tmp}/peon-py-$$.py")
cat > "$_PEON_PY_TMP" <<PEON_LOCAL_PY_EOF
<same block body, unchanged — unquoted heredoc preserves ${_PEON_STATE_PY_HELPERS} expansion>
PEON_LOCAL_PY_EOF
_PEON_PYOUT=$(python3 "$_PEON_PY_TMP" <<< "$INPUT" 2>/dev/null)
rm -f "$_PEON_PY_TMP"
# was: " <<< "$INPUT" 2>/dev/null)

After patching, the same repro invocation now logs normally:

[config] loaded=.../config.json volume=0.5 pack=peasant enabled=True
[hook] event=Notification session=test cwd="" paused=False
[route] category=none suppressed=True reason=unknown_notification
[exit] duration_ms=4 exit=0

And PreToolUse events from real Claude Code tool calls now show up in logs/peon-ping-<date>.log across the whole session.

Just a data point that this is still affecting the current release — would be great to see one of the suggested upstream fixes land.

[lmagine]

One follow-up observation after the workaround: end-to-end sound latency is ~3 s on Windows, which means the audio cue lands after the user has already clicked through the permission dialog.

Breakdown from peon debug logs on a patched v2.22.0:

T+0    ms  [hook]    event=PermissionRequest
T+3    ms  [sound]   file=PeasantWhat4.wav chosen
T+2284 ms  [notify]  desktop=False rendered=claude   ← ~2.3 s of pre-play work
T+2953 ms  [play]    backend=msys2 async=true

Even with peon notifications off (no overlay, desktop=False confirmed in log), the [sound] → [play] gap stays ~2.3 s. The [sound] → [notify] path seems to be doing non-async work before dispatching playback.

Would it be possible to move the actual play dispatch right after [sound] (before the notify phase), so the audio starts as close to T+0 as possible? Happy to contribute a PR if that's welcome — just wanted to flag the symptom while the root-cause issue is open.

[garysheng]

Thanks for the precise root cause, the trace + line numbers + the exec-path explanation made this trivial to verify on my end. You're right that this only surfaces on Windows because Linux execve and macOS limits are in the megabytes, while CreateProcess argv is capped near 32 KB. The consolidated Python block in peon.sh is well past that with the state-helper injection.

Your workaround is the right shape (write the inline Python to a tempfile and invoke by path; $INPUT still goes via stdin). Two things to do alongside the path swap:

1. Drop the 2>/dev/null on that exec so the next failure mode this hits surfaces in peon debug status instead of looking like nothing happened. Silent stderr there is what masked this for so long.
2. Make the tempfile cleanup defensive: trap 'rm -f "$_PEON_PY_TMP"' EXIT so we don't strand 30 KB of Python in %TEMP% when the hook is interrupted.

Native Windows installs (powered by peon.ps1) don't go through this path, so the fix is scoped to the bash-on-Windows (msys2 / git-bash) flow.

PR welcome if you want to send the fix you're already running locally. Otherwise I'll cycle back to it shortly. Thanks again, this was a great bug report.