DEV Community: Chikoku_NEKO

A Batch-File Shim Was Truncating My Agent's Prompts on Windows (3/24 to 21/24)

Chikoku_NEKO — Sun, 16 Aug 2026 16:05:33 +0000

Environment: Windows 11 Home, Python 3.x, Claude Code installed via npm install -g @anthropic-ai/claude-code. Measured 2026-08-14 to 2026-08-16.

I was comparing two agent harnesses on the same set of web tasks. The first run of harness B scored 3 out of 24. I didn't touch the model and I didn't touch the prompt wording. I changed only how the prompt reached the process, and the score went to 21/24. Here is what was actually broken.

What happened

I was running an eval to see how well current agents handle routine web work, the kind a triage process would flag as "candidate for RPA." Two harnesses, same 8 tasks:

Harness A: the computer use API directly (claude-sonnet-5, max_turns=40), 8 tasks x 1 trial.
Harness B: Claude Code headless (claude -p) plus Playwright, same model, 8 tasks x 3 trials = 24 runs.

Success in both harnesses is decided by machine verification only: submitted form payloads compared against expected JSONL, downloaded files checked for existence and size, answers matched by regex. The agent's own claim of "done" is never trusted as a success signal.

First run of harness B: 3/24. Only the first task passed. I assumed the model was the weak link and started digging into what harness B was actually sending it.

The core finding: a multi-line prompt loses everything after the first newline

On Windows, when you drive claude -p from Python via subprocess and let shutil.which resolve the executable, a multi-line prompt gets truncated at the first newline before the process ever sees it. Everything after line 1 is silently dropped.

Root cause: the npm global install of Claude Code puts a file named claude.CMD on PATH. That's the file shutil.which("claude") resolves to — not the real executable. It's a batch wrapper. Its body is:

"%dp0%\node_modules\@anthropic-ai\claude-code\bin\claude.exe"   %*

Let me separate what I measured from what I'm inferring.

What I measured: swapping only argv[0] between the two paths changes the outcome. Point it at claude.CMD and the tail is gone; point it at claude.exe and it arrives. Prompt, flags, and environment are identical, so the difference is the shim.

What I'm inferring: %* is cmd.exe's mechanism for forwarding arguments to the wrapped command, and the newline appears to be lost in that forwarding. I have not isolated which layer drops it (cmd.exe's argument expansion, the shell Python interposes when executing a .CMD, or both). Either workaround below is sufficient without knowing, so I stopped there.

Minimal reproduction:

import os, subprocess

EXE = os.path.join(os.environ["APPDATA"], "npm", "node_modules",
                   "@anthropic-ai", "claude-code", "bin", "claude.exe")
CMD = os.path.join(os.environ["APPDATA"], "npm", "claude.CMD")
PROMPT = "Follow the instruction below exactly.\nOutput the string MARKER_TAIL_9137 and nothing else."

for label, argv0 in (("claude.CMD (shim)", CMD), ("claude.exe (direct)", EXE)):
    r = subprocess.run([argv0, "-p", PROMPT], capture_output=True, text=True,
                       encoding="utf-8", errors="replace", timeout=180)
    out = (r.stdout or "") + (r.stderr or "")
    print(label, "tail_received =", "MARKER_TAIL_9137" in out)

Measured result:

claude.CMD (shim): tail_received = False. The model's reply asks for the missing instruction, having seen only line 1: "Follow the instruction below exactly."
claude.exe (direct): tail_received = True.

There are two fixes:

Resolve and call claude.exe directly instead of trusting whatever shutil.which("claude") returns.
Normalize newlines to spaces in the prompt before passing it. This is the more portable option, since it sidesteps the shim regardless of platform.

This is hard to catch because there's no exception, no non-zero exit code, and no warning anywhere in the pipeline. cmd.exe forwards a truncated string and everything downstream treats it as a normal, well-formed prompt. The only symptom is a low success rate, which looks identical to "the model isn't capable enough for this task." I spent time suspecting the model before I suspected the wrapper.

How harness B's score moved (measured)

3/24: first run. Only the first task passed. The prompt never actually included the target URL — I'd assumed the model could infer it from task context, which was wrong for a browser-driving harness. Harness A never surfaced this, because in harness A I navigate the browser to the URL programmatically before the agent's turn starts, so the missing URL in the prompt didn't matter there.
6/24: after adding the URL to the prompt. Only tasks whose instruction was a single line started passing; multi-line task instructions still failed. That asymmetry is what led to the newline finding — the agent's own reply, when it failed, said the instruction seemed cut off, and the cutoff point matched exactly where the newline sat in the task definition.
23/24: after normalizing newlines. I discarded this number. Harness B had no --model flag set and was running on whatever the CLI's default model was, so this result wasn't comparable to harness A, which was pinned to sonnet-5. Confounded comparison, not a usable data point.
21/24: after pinning both harnesses to claude-sonnet-5 explicitly and re-running. This is the number I'm keeping.

The measurement itself

Harness A: 6/8 successes, 993.9 JPY total. Both failures were turn-limit cutoffs, not wrong answers: a 10-row transcription task finished 1 row before hitting the cap (251.7 JPY spent), and a 3-item conditional submission task finished 1 item before the cap (283.4 JPY spent).
Harness B: 21/24 successes, 0 JPY (covered under a flat-rate plan, so no marginal API cost). All three failures were over-submission — the agent submitted 11 entries where 10 were expected, and separately 4 where 3 were expected.
On harness A, what separates cheap runs from expensive ones is submission count, not task difficulty. Tasks that were read-once-answer-once finished in 5 to 7 turns at 12 to 24 JPY. Tasks requiring repeated submissions burned through all 40 turns and only completed 10 to 33 percent of the required work.
993.9 JPY is an estimate, not an invoiced amount. It's derived from list pricing ($3 input / $15 output per Mtok) converted at 150 JPY per USD.
Caveat: the stop conditions are asymmetric. Harness A had max_turns=40 plus a 600-second timeout; harness B had only the timeout, no turn cap. Part of the 6/8 vs 21/24 gap comes from that difference, so don't read those two numbers as a head-to-head ranking. The claim of this post is the within-harness-B change, 3/24 to 21/24.

Closing

Success rate is the product of model capability and harness quality, and the two are easy to conflate when the harness fails silently. Before concluding a model can't do a task, I now check four things: is the target (URL, path) actually present in what gets sent; is the full instruction arriving intact (print the exact prompt the process received, and read it — don't assume); can the agent actually reach whatever files it's supposed to produce or read; are model and stop conditions pinned explicitly on both sides being compared.

If I'd taken that first run at face value, I would have reported that Claude Code plus Playwright can't handle routine web work. The cause had nothing to do with the model: a batch file was dropping everything after the first newline.

Claude Code hooks looked like they stopped firing on MCP tools — it was my own hook crashing"

Chikoku_NEKO — Wed, 12 Aug 2026 17:59:41 +0000

Correction (2026-08-14): the main claim in this post is wrong.

I wrote that PreToolUse hooks stop firing for MCP tool calls after the hook returns a deny.
They don't. The hook fired every time. What failed was my own hook script, which crashed
on MCP payloads. This is not a Claude Code bug.

I re-ran the same setup (Claude Code 2.1.227, same machine) with a hook that writes one
unconditional line before it parses stdin:

stage	count
hook invoked	10 (including all 3 MCP calls)
payload parsed	10
row written	7 (non-MCP only)
exception	3 (all `mcp__ollama__summarize_file`)

The exception:

UnicodeEncodeError: 'utf-8' codec can't encode character '\udc86'
  in position 353: surrogates not allowed

The cause has nothing to do with Claude Code or MCP. Python on Japanese Windows decodes
piped stdin as cp932, which mangles UTF-8 Japanese text into lone surrogates. Here is the
whole thing without Claude Code involved:

$ echo '{"x":"順"}' | python -c "import sys; print(repr(sys.stdin.read()))"
'{"x":"�\udc86"}\n'

My hook logged tool_input. For Read that is just an ASCII file path. For the MCP call the
model passed a Japanese instruction as an argument, so only MCP payloads contained non-ASCII.
This is not MCP-specific at all — any tool whose arguments contain non-ASCII would do it.

Changing sys.stdin.read() to sys.stdin.buffer.read().decode("utf-8") — one line — makes
the MCP rows appear, 3 sessions out of 3.

Why it looked deny-dependent: without a deny the model just reads the file and stops, so it
never calls the MCP tool at all. MCP calls only happened in sessions that had a deny, so those
were the only sessions missing rows. The deny wasn't the cause; it was what made the model
reach for the MCP tool.

I checked whether Claude Code was sending malformed bytes. It wasn't — I captured the raw
stdin with sys.stdin.buffer and all six payloads are strictly valid UTF-8. The 0x86 byte
is the third byte of \xe9\xa0\x86, U+9806 「順」.

No issue was filed against anthropics/claude-code, and none should be. The body below is
preserved as published, with each wrong claim struck through and corrected inline.

TL;DR

I tried to cut Claude Code's token use by having a PreToolUse hook deny Read and redirect the model to a local LLM summary tool.
The hook log contained not a single row for the local summary tool. But the tool was being called. Once a PreToolUse hook returns a deny, hooks stop firing for the rest of that session's MCP tool calls (built-in tools are unaffected). Confirmed on Claude Code 2.1.227 / Windows 11 Home, 2026-08-12. Correction: the hook fired every time. The missing rows were my own hook crashing on cp932-mangled stdin (see the correction above).
There's a five-minute repro below. ~~Every claim in this article can be checked by running it, without taking my word for anything.~~ Correction: what the repro reproduces is not a hook failure — it's the sys.stdin.read() bug inside the repro's own hook.py.
The feature itself is a no-go. Local summaries invent facts, so the model either re-reads the original to verify (which cancels the savings) or skips verification and ships a wrong answer. That's structural, not a matter of model size.

Minimal repro

Here first. Any stdio MCP server will do.

Project .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "*", "hooks": [
        { "type": "command", "command": "python /abs/path/hook.py" }
      ]}
    ]
  }
}

hook.py — logs every call unconditionally, before any branching, and denies only Read:

import json, sys
p = json.loads(sys.stdin.read())
open("log.jsonl", "a").write(p.get("tool_name", "") + "\n")   # unconditional
if p.get("tool_name") == "Read":
    print(json.dumps({"hookSpecificOutput": {
        "hookEventName": "PreToolUse", "permissionDecision": "deny",
        "permissionDecisionReason": "use mcp__<your>__<tool> instead"}}))

In one session, get Read denied, then call the MCP tool:

claude -p "First try reading foo.md with Read. If it's blocked, use mcp__<your>__<tool>" \
  --allowedTools "Read,Grep,Glob,Bash,mcp__<your>__<tool>"

log.jsonl will show Read and the built-ins, but no row for the MCP tool. The MCP server's own request log shows the call went through.

Correction: the missing row is caused by line 2 of this very hook.py. On Japanese Windows, Python decodes piped stdin as cp932, so an MCP argument containing Japanese arrives as lone surrogates and the write dies with UnicodeEncodeError. Replace sys.stdin.read() with sys.stdin.buffer.read().decode("utf-8") and every row appears.

What would falsify this: finding a case where the MCP tool is called with no prior deny and the hook row is still missing. Then the cause is something other than the deny.

Correction: this falsification condition was in fact met. Any non-ASCII argument drops the row, deny or no deny. My no-deny trials all logged fine only because their arguments happened to be pure ASCII.

What I wanted

I wanted to cut Claude Code's token consumption. On a flat-rate plan the bill doesn't change, but the rate limit does, and my nightly cron jobs eat into it.

The idea: hand file reads off to a local model. When Read pulls in a big file, the content stays in context and gets billed on every following turn. Summarize it with Ollama at the entrance and that recurring cost disappears.

I decided to do it with hooks. A hook is an external script that runs right before a tool executes; the PreToolUse kind can return a deny that stops the tool and hands a reason string back to the model. I used that to block Read and put "use mcp__ollama__summarize_file instead" in the reason. That Ollama summary tool is wired in over MCP, so it's an external tool, a separate class from built-ins like Grep. That distinction matters later.

I didn't know whether the model would call the local tool on its own, so the first thing to measure was whether a denied Read actually led to the local summary being used.

The measurement was broken

I wrote five fixtures (deploy notes, a 120-line changelog, a config reference, an incident report, an API spec) and ran trials headless with claude -p.

The hook log had no rows for the local summary tool. Read denials were there. Grep was there. ToolSearch was there. Only the summary tool was missing. It looked like the redirect had failed completely.

Except the model's answers said otherwise:

Processed locally with Ollama.

The Ollama summary misreported the range as "Jan–Sep"; checking the tail showed it actually ends in March.

It says it used the summary. It comments on the content of what it used. The log says it never called the tool. One of them is wrong.

I looked at a third record: the Ollama server log. Throughout the trial window, /api/generate was being hit repeatedly.

[GIN] 2026/08/12 - 03:32:17 | 200 | 22.44s | 127.0.0.1 | POST "/api/generate"
[GIN] 2026/08/12 - 03:33:20 | 200 | 21.20s | 127.0.0.1 | POST "/api/generate"
...

The model called the tool, the server answered, and the hook passed it through without logging it.

An empty hook log has three possible causes: the hook never ran, it ran but threw after the deny branch and failed to write, or it wrote and the write got lost. The logging line sits before any branching, and the same sessions do contain the Read denial and the ToolSearch call — so "ran but failed to write" would still have left a row. That leaves "never ran."

Why the hook was blind

Correction: this section's conclusion and the control matrix below are retracted. The deny was a confounder, not the cause. Without a deny the model just reads the file and never calls the MCP tool, so MCP calls (= Japanese arguments = hook crash) only existed in deny sessions. The correct observation is the table in the correction above: 10/10 hook invocations, 3 exceptions, all of them MCP calls.

I changed one condition at a time and reproduced each. The conclusion first. Once a PreToolUse hook returns a deny anywhere in the session, hooks stop firing for subsequent MCP tool calls. Built-in tools (Grep, Glob) keep firing after the deny. Only MCP tools are affected, and the trigger is a prior deny.

"matcher" is the hook-config field that says which tools the hook applies to: * means all tools, a literal name means one specific tool. The last column is the observation — whether the hook managed to log that MCP call.

matcher	deny earlier in session	hook fires on MCP call
`*`	no	fires
`*`	yes	does not fire
`*`	yes (tool named explicitly)	does not fire
`*`	no (only emitted allow JSON)	fires
literal name	no	fires

The three no-deny rows fire. Only the two deny rows don't. Everything else is held constant, so the prior deny is what's doing the work.

Two more checks. First, I attached the same logging hook to PostToolUse and re-ran it. After a deny, the MCP call shows up in the PostToolUse log as mcp__ollama__summarize_file — and still not in PreToolUse. The hook system is alive; PreToolUse just isn't seeing MCP.

Second, killing a rival explanation. In this setup MCP tools are lazily loaded: the model calls ToolSearch to pull the tool in before using it. So "hooks don't fire for tools loaded mid-session via ToolSearch" would explain the same observations, and it correlates perfectly with the deny. The table alone can't separate them. So I swapped in a log-only hook that never denies, and ran a control where the model loads the tool through ToolSearch and then calls it.

16:12:47 ToolSearch
16:12:51 mcp__ollama__summarize_file   ← logged

A ToolSearch-loaded MCP tool does fire the hook, as long as nothing denied earlier. The load path isn't the cause.

Scope of what I checked

Claude Code 2.1.227, Windows 11 Home, on 2026-08-12
No other OS or version tested; I can't say whether this is Windows-specific
One stdio MCP server, one tool
n=1 per cell in the table

~~The docs say "MCP server tools appear as regular tools in tool events," so at minimum this isn't the documented behavior.~~ Correction: the behavior matched the docs. Hooks fired on every MCP call.

Implications

Correction: this section's premise (hooks not firing) is wrong, so both implications below are retracted. What survives, for a different reason: when a hook script crashes, auditing and enforcement both silently disappear — exit status ignored, no row, no warning.

~~One is observability: a hook-based audit log records nothing for MCP in any session containing a deny. You can no longer distinguish "not used" from "not logged."~~

~~The other: since PreToolUse deny is the documented way to control whether a tool may run, every MCP call after the first deny slips past that control.~~

Don't over-read it, though. What's bypassed is hook-level control and auditing; permission rules and confirmation prompts are a separate layer and still apply. There's no remote attack surface either — exploiting this needs local settings and a registered MCP server on the target machine. The people it hurts are the ones enforcing policy through hooks and the ones counting usage from hook logs.

The local summary itself

With the measurement fixed, here's what the summaries actually looked like. The local model was qwen2.5-coder:7b.

They invented content that wasn't in the file. The detection shows up in the model's own answers:

The Ollama summary output "error-format JSON," "pagination (next token)," and "Authorization header format," but none of these exist in the actual file. The real content is one line per endpoint.

Checking the fixture confirms it: each endpoint is a single line, Returns resource N. Auth: bearer. Rate limit: 100/min., with nothing about error formats or pagination.

In most runs the model caught this, threw the summary out, and re-read the original with Grep. But not every time. One changelog summary came back as "final value 756ms, continuing to around 2026-09." The last line of the file reads 2026-03-12 fix: adjust retry backoff to 833ms. Wrong value, wrong date. The answer carried a hedge ("ask for another method if you need the original verified exactly"), but a hedged wrong answer still went out.

That's where the idea died. Verify the summary and the savings go into verification; skip verification and wrong answers get through.

I only tested 7B against five fixtures, and a 14B or 32B would fabricate less. But the reason this fails isn't accuracy, it's structure. A model that doesn't trust the summary reads the original to check, and that verification cost cancels the savings. A model that trusts it answers from degraded input and takes on the error risk instead. Better accuracy shrinks the fabrication, but it just turns into a judgment call about whether the summary is trustworthy enough to skip checking — which is not the same as the inserted layer paying for itself.

Verdict

I dropped the feature. Three reasons.

I wouldn't use it myself. Trading answer quality against the reason I use a frontier model in the first place is backwards.

There's a substitute inside the product. If you're about to hit the rate limit, switch to Sonnet or Haiku with /model. Quality stays frontier-grade and no extra tooling is needed.

It doesn't save anything. Verify and the cost comes back; skip verifying and you ship errors.

~~Some questions I didn't chase: whether a fresh session restores the hook, whether slipping one allow in after the deny brings it back, whether any of this holds outside Windows.~~ Correction: these questions dissolved along with their premise.

A note on how this article was written

I rewrote the numbers three times before publishing.

The first version reported a redirect success rate of 0% — a figure computed from the very log I had just shown to be broken, and I used it without hesitating. The second time I corrected that figure for one model and considered the job done. The third time, I trusted a log file's name and quoted one model's words as another's: I'd launched the trials without --model, so switching the session's model mid-run mixed two models into one file. I noticed the mixing while it was happening, and then trusted the filename anyway when it came time to tally things up.

All three were caught by someone else pointing at them. The common thread is that I stopped checking the moment a coherent explanation was available. The number matched the quotes, the filename matched my expectation, and that was enough to stop.

So I removed my own aggregate numbers from this article. What's left is whether a row exists in a log, plus specific cases checked against the original file. The repro sits at the top for the same reason: run it, and you can verify this article's claim without trusting my arithmetic.

A broken instrument returns zero. Zero reads as "it didn't happen," which draws far less suspicion than a strange value would. The moment the numbers agree with what you expected is probably the most dangerous one.

Silent Failures in Unattended AI Agents — How I Built a Postmortem Tool to Find Them

Chikoku_NEKO — Tue, 11 Aug 2026 17:43:46 +0000

A cron-scheduled agent of mine ran fine: exit code 0, no stderr. But the weekly report it was supposed to write never appeared, and nothing told me. I only noticed days later, checking the directory by hand.

I call this a silent failure, and I think it's the nastiest failure mode of unattended agents: the job reports success, so no alerting ever fires, and the only detection mechanism left is a human happening to look. I built agent-coroner to catch these automatically. v0.1.0 is now on GitHub, PyPI, and the Claude Code plugin marketplace.

What happened

For five weeks straight, my weekly-report job ran without a problem. It pulled data, generated markdown, wrote a file every Friday morning. I didn't monitor it actively, because it was boring infrastructure that appeared to be working.

Week six: no report. The logs showed nothing obviously wrong, and the job had no alerting of its own. By week seven it had recovered on its own and everything looked normal again. To this day I haven't root-caused that one missing week. That's the part that bothered me most: without an artifact check, I wouldn't even have known it happened.

The design

Instead of trying to guess when things go wrong, I decided to be explicit about what each job should produce, then check those promises deterministically. There are three layers.

The first layer is a contracts file, where you declare what each job promises:

jobs:
  weekly-report:
    schedule: "FRI 08:30"
    grace_minutes: 60
    artifacts:
      - path: "reports/weekly-*.md"
        max_age_hours: 192
        min_bytes: 500
    logs: "run.log"

The second layer is the checker, a small CLI you run from cron or Task Scheduler. It asks four questions: does the file exist, is it fresh (max_age_hours), is it big enough (min_bytes), and did your optional verify command pass. No LLM is involved, so a run takes seconds and ongoing monitoring costs nothing. It exits non-zero if a contract is violated and zero otherwise, so you can wire it into any alerting you already have.

The third layer is the autopsy. Only when a contract breaks, Claude is dispatched read-only (--allowedTools "Read,Grep,Glob") to read the logs and write a four-section postmortem: facts, hypotheses ranked by confidence with log quotes, verification steps for a human to run, and prevention suggestions. It diagnoses; it never modifies anything.

One design decision worth spelling out: detection never depends on the LLM. The checker always runs first, and if the autopsy crashes, the violation notification still goes out. There's also no self-healing on purpose. Once you let an LLM patch things in an unattended system, failures start getting hidden instead of reported, and I trust a monitor that only reports.

Dogfooding it on a new project

The day after publishing, I started a new project (a paper-trading eval that forecasts day-ahead prices on JEPX, Japan's electricity exchange) and registered its weekly accuracy report as a coroner contract. Just building and registering that pipeline surfaced two traps of exactly the kind the tool exists for.

The first trap: the JEPX CSV endpoint returns HTTP 200 with a zero-byte body when the Referer header is missing. Success code, no data. I caught it with curl while writing the fetch layer. A status-code-only check would have "succeeded", saved an empty file, and quietly poisoned everything downstream. The defense is now two layers deep: the fetcher rejects empty bodies outright, and the contract's min_bytes rule guards the artifact. If one goes quiet, the other still fires.

The second trap: my monitored artifacts live in a different repository on a different drive, so I wrote the contract with an absolute-path glob, and the checker crashed. Glob resolution is delegated to pathlib's relative globbing, so absolute paths don't work. The fix is to set workdir (which defaults to the directory containing contracts.yaml) and use a relative glob. After rewriting it, the checker passed: power-eval-weekly: ok, exit 0.

I found the second one funny in hindsight. Putting the verification tool into real service exposed a gap in the verification tool's own docs, so the verifier got verified. The README now documents workdir and the relative-glob rule.

Quick start

Install:

uv tool install agent-coroner   # or: pip install agent-coroner

The claude CLI on PATH is required only for autopsies; the checker works standalone.

Write contracts.yaml:

jobs:
  weekly-report:
    schedule: "FRI 08:30"
    grace_minutes: 60
    artifacts:
      - path: "reports/weekly-*.md"
        max_age_hours: 192
        min_bytes: 500
    logs: "run.log"

Run the checker:

$ coroner check --config contracts.yaml --no-autopsy
[coroner] 1 violation detected
- weekly-report / reports/weekly-*.md: missing (no file matches 'reports/weekly-*.md' under <contracts-dir>)
$ echo $?
1

Once reports/weekly-*.md exists, is fresh, and meets min_bytes:

$ coroner check --config contracts.yaml --no-autopsy
weekly-report: ok
$ echo $?
0

*/15 * * * * coroner check --config /path/to/contracts.yaml >> /var/log/coroner.log 2>&1

On Windows:

schtasks /create /tn "coroner-check" /tr "coroner check --config C:\path\to\contracts.yaml" /sc daily /st 09:00

Notifications are delegated to an external command of your choice (email, Slack, whatever), with {message_file} holding the path to the full message text.

Claude Code integration

If you use Claude Code, there's also a plugin:

/plugin marketplace add Chikoku-NEKO/agent-coroner
/plugin install agent-coroner@agent-coroner-marketplace

It adds /coroner-status (which jobs are ok, which have violations), /autopsy <job-name> (run a postmortem on demand), and a SessionStart hook that surfaces unread postmortems when you open a session.

Closing

If you run anything unattended that's supposed to produce an artifact — weekly reports, data pipelines, scheduled Claude jobs — an existence-and-freshness check on the artifact is cheap insurance, whether or not you use this tool. agent-coroner just makes it declarative: one YAML file, a deterministic checker, and a read-only postmortem when something breaks.

Links:

GitHub: https://github.com/Chikoku-NEKO/agent-coroner
PyPI: https://pypi.org/project/agent-coroner/
Claude Code marketplace: agent-coroner plugin

If you try it and something breaks during registration, file an issue. That's how the two traps above got documented.