claude-protocol-debugger
Skill44 starsChanged 3 months agoMITView on GitHub
Use when investigating Claude CLI protocol behavior — stream-json event mismatches, permission handling, control_request/response fields, or any question about what the CLI actually does internally. Covers live event debugging, JSONL history comparison, and binary reverse-engineering.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- assistant-uiSkill
- changelog-watchSkill
- codex-protocol-debuggerSkill
- mainframe-design-systemSkill
- radix-ui-design-systemSkill
- release-downloadsSkill
- shadcnSkill
- tauri-v2Skill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 77
All previously reverse-engineered details (string literals, minified function tables, call chains, two code paths for control_request, …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Claude Protocol Debugger
Overview
The Claude CLI communicates via a JSON-RPC-like protocol over stdio. This skill covers three debugging techniques:
- Live event inspection — debug mismatches between stream-json events and JSONL history
- Daemon log analysis — inspect control_request/response payloads as logged by the daemon
- Binary reverse-engineering — read the CLI's minified JS source to verify protocol behavior
When to Use
- Feature works after daemon restart (history path) but not during live sessions
- Fields are missing or named differently in live mode vs JSONL
- Permission responses aren't being persisted or honored
- Need to verify what the CLI actually does with a protocol field
- Investigating undocumented CLI behavior or protocol edge cases
Technique 1: Live Event Inspection
For snake_case vs camelCase field mappings, debug logging patterns, and daemon log analysis techniques, see protocol-findings.md. Read it before starting any event debugging.
Technique 2: Daemon Log Analysis
See protocol-findings.md for grep patterns and Python extraction scripts.
Technique 3: Binary Reverse-Engineering
The Claude CLI binary is a bundled Node.js SEA (Single Executable Application) with readable minified JS embedded in it. Use this when docs are incomplete or you need to verify what the CLI actually does with a protocol field.
Before re-reversing the binary, read
cli-binary-internals.mdin this directory. It contains previously reverse-engineered findings (v2.1.85) including the stdio message loop, interrupt handling, REPL bridge, abort controller chain, and background agent wait loop. Read it first to avoid duplicate work.
Locate the binary
# Find the CLI version and binary
claude --version # e.g. 2.1.85
ls ~/.local/share/claude/versions/
# Binary is at: ~/.local/share/claude/versions/<version> (the version IS the binary, not a directory)Extract and search the JS source
Prefer Python re.finditer over strings | grep — the binary contains enormous minified JS lines, and strings | grep returns megabytes of irrelevant context. Use offset-based extraction:
import re
CLI_BIN = "~/.local/share/claude/versions/2.1.85" # adjust version
with open(CLI_BIN, 'rb') as f:
data = f.read()
# Search for exact byte pattern
pattern = b'case"interrupt"'
for m in re.finditer(pattern, data):
start = max(0, m.start() - 300)
end = min(len(data), m.end() + 500)
chunk = data[start:end].decode('ascii', errors='replace')
print(f'=== offset {m.start()} ===')
print(chunk)For broader searches, strings still works but pipe through wc -l first to gauge volume:
CLI_BIN=~/.local/share/claude/versions/$(claude --version | head -1)
strings "$CLI_BIN" | grep -c "your_pattern" # check count firstPrevious findings
All previously reverse-engineered details (string literals, minified function tables, call chains, two code paths for control_request, permission persistence, interrupt handling, background agent wait loop) are in cli-binary-internals.md. Read it before starting any new reverse-engineering session.
Maintaining Reference Files
This skill has two reference files that accumulate findings across debugging sessions. Update them when you discover something surprising — behavior that contradicts expectations, undocumented protocol quirks, or anything that would save time if known upfront next time.
| File | Contents |
protocol-findings.md | Protocol-level knowledge: event pipeline, field casing, daemon log analysis, debug logging patterns, common pitfalls |
cli-binary-internals.md | Binary reverse-engineering: minified JS structure, code paths, abort chains, agent wait loops, permission persistence |
What to record: Things we didn't expect — behavior that surprised us, fields that don't match docs, race conditions, blocking issues. Don't record things that are obvious from reading the code.
What NOT to record: Routine findings that match documentation, expected behavior, or things derivable from reading source files.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

