[ThomasK33]

Why

The operator asked for a code-shape refactor of the plugin, landed on main in small PRs, fixes first. His rule for the verification skill: a scratch harness that catches a blocker goes into the repo's skill, and memory points at repo paths. The wire probe that caught the blockers of #500 over four review rounds lived only in a scratch folder, so the next agent could not run it. This PR puts it in .agents/skills/verify-claudecode-nvim.

What changed

Three new files under .agents/skills/verify-claudecode-nvim. No existing file, no lua/, plugin/, tests/, scripts/ or .github/ file changes (425 added lines, above the 300-line aim: the launcher, the checker and the page are all in it).

• scripts/proof-tools-call-wire.sh [tree] is the one command. It starts the plugin server of tree (default: this checkout) in one headless nvim and runs the checker. Exit 0 pass, 1 a case failed or a frame leaked, 2 the probe could not run or judged fewer cases than the table holds.
• scripts/proof-tools-call-wire.mjs holds the case table, the WebSocket client and the checker. It prints one ok: or FAIL: line per case and ends with COUNT tools-call-wire cases=<n> failed=<n> leaks=<n>.
• features/tools-call-wire.md is the feature page: the command, a pass and a fail, the red proof, the normalization.

Rules in the script:

• Each case is a row of one table: name, params, expected answer. A refusal names the parameter (-32602, and the data names it). A normal answer is written out whole. The tools, argument shapes and wrong values are expanded from short lists into rows, and the checker has one path for every row.
• Normalization sits next to the table. The leak rule and the token rule read the text of every frame that the server sends as the wire sent it, and no parse or rebuild comes first. One step comes before them: every escaped slash, a run of backslashes and a slash at any depth of nesting, is read as a slash. Then the path rewrite applies to that text: the folder nvim runs in becomes $CWD, the plugin tree $TREE, the real home folder $HOME, in that order. A frame leaks when its text then holds .lua: and a digit, $TREE or $HOME, or 8 or more characters of the auth token in a row. So a path in a sibling field, an object key, a nested list, a duplicate key or a JSON fragment inside a plain string leaks. It also reads a frame that comes before the answer, or within 200 ms after the last answer, and counts a frame for one case only. A frame that arrives after its own answer is judged with the case in flight. The comparison with the table reads a rebuilt copy of the answer that rewrites strings but not keys, so two keys that the rewrite would make equal never pass as a correct answer. The leak rule finds each of the three paths in a frame unchanged, so the probe refuses to run when the tree path, the work folder path or the real home folder path holds a double quote, a backslash or a control character (the characters that JSON writes escaped). It exits 2 with a message that names the path, before it sends a case. A backslash in the tree path can make nvim fail to load the plugin first: the script then exits 2 with nvim wrote no lock file in 10 s. The workspace folder is not a leak: getWorkspaceFolders returns it on purpose, and its expected answer is {"folders":[{"name":"work","path":"$CWD","uri":"file://$CWD"}],"rootPath":"$CWD","success":true}.
• A pass needs at least one case and every row judged: an empty table, or fewer judged cases than rows, exits 2 and prints no COUNT line. The cases= count is the number of cases that the checker judged.
• Safe launch: nvim and the checker start with an empty environment. When nvim and node are the binaries themselves, nvim gets only PATH=/usr/bin:/bin, WIRE_PARENT, WIRE_TREE, WIRE_CWD, and HOME, TMPDIR, XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_STATE_HOME, XDG_CACHE_HOME and CLAUDE_CONFIG_DIR in /tmp/wire-probe.XXXXXX (from mktemp -d, mode 0700), and the checker gets no variable. A version-manager shim that does start adds variables of its own. nvim runs with terminal.provider = "none". The script exits 2 when a claude program is on PATH=/usr/bin:/bin, when nvim or node does not start with an empty environment (a version-manager shim does not), and when the temp dir cannot be made. nvim must be a direct child of the script: it checks its parent before the plugin starts, and when the parent is not the script (a wrapper that runs Neovim without exec) it quits with an error, so no server starts and no lock file is written. The script then exits 2 with a message that names the wrapper and says to set VCN_NVIM to the Neovim binary itself. A wrapper that uses exec passes. When the server does not come up for another reason, the script prints the last lines of nvim's output.
• The token: it lives in the memory of nvim and of the checker, and in the 0600 lock file in that folder. The checker sends it only in the upgrade header. The checker prints only text that it wrote itself (stop) and the text of a frame that passed show, which withholds a text that holds 8 or more characters of the token in a row (the output says <holds the auth token>). It never prints the message or the stack of an exception that Node or a library raised, because such a message can quote its input (the WebSocket constructor quotes the header value): a frame that is not JSON and a lock file that does not parse end the run with exit 2 and a fixed message, and any other exception ends it with exit 2 and one line that holds only the exception's class name. When the server does not come up, the script prints the last lines of nvim's output. That happens only while no lock file exists, and the plugin logs only the length of its token. On a normal exit, a failed case, TERM, INT and HUP, the script stops nvim and the checker by PID (it polls for their end and sends SIGKILL, and does not wait for them) and removes the folder. After SIGKILL no cleanup runs: nvim, a direct child of the script, checks its parent every half second and quits, its server stop removes the lock file and closes the socket, and the checker exits on the closed socket. Both processes and the lock file are gone within 5 seconds (the bound the script holds to; 0.41 s at most in the 10 runs below). The folder stays then, with no token in it.
• Why not vcn.sh launch: it starts a TUI in agent-tty (agent-tty, Chromium) and puts this checkout on the runtimepath, so it takes no tree argument, which the red proof needs. The probe keeps the skill's conventions: VCN_NVIM, node from mise which node, and a client that takes the token from the 0600 lock file as ws-client.mjs does. It does not call vcn.sh, so fix(skills): check the state dir once, not each run.env, and resolve TMPDIR once #506 does not change how it runs.

Cases in this PR, and the cases left out

44 cases: params absent, false, null, true, a number, a string, [], [1] (all name params) and {} (names name). A non-string name (8 values). For getWorkspaceFolders and openFile: arguments absent, {} and each of the 7 non-object values, and for openFile each wrong type of filePath (8 values) plus "".

Left out, all for size: the other nine tools (getOpenEditors, getCurrentSelection, getLatestSelection, closeAllDiffTabs, getDiagnostics, checkDocumentDirty, saveDocument, close_tab, openDiff) with their string parameters and the getDiagnostics uri, the ctl_* valid-call controls, and the two notification cases of the scratch wire3.lua. They are the next PR, which adds table rows and the silent-answer check. The index lines (SKILL.md Helpers and features/README.md) are not in this PR either, because #506 and #508 are open and change those files. They go in the next PR.

How I proved it

Neovim 0.12.3 and the official v0.8.0 release, each three runs in a row, from the head of this branch (merged with main 4c1df79. Main has moved since to c9e57d13, which changes nothing in the skill folder or in these three files, so I did not merge it, and a run on a tree of c9e57d13 printed the same line on both versions): every run printed COUNT tools-call-wire cases=44 failed=0 leaks=0 and exit 0, and the six outputs are byte-identical.

Red proof (git archive f932d7b6a91c71c3728257ae6284bf03f9d09c77, main before #500), exit 1 on both versions:

COUNT tools-call-wire cases=44 failed=30 leaks=15

Round 3 (findings from the third review round, my proofs on this head):

• A tree path with a double quote (vim.json.encode writes " as \", so the rewrite to $TREE misses it). The mutant that puts the tree path into an object key of an answer, in the folder /tmp/wp517-q"t/: the previous head exits 0 with cases=44 failed=0 leaks=0 on both versions, and this head exits 2 with the message above and no ok: line on both versions. The same mutant in a plain path stays red (failed=2 leaks=2), and the mutant with the tree path in every refusal gives failed=31 leaks=31. The checker alone refuses a quote in the tree, in the work folder and in the home folder, on Node 22.23.4 and 26.12.1. A tree path under the real home folder is read as $HOME, so the old gap shows only outside it. A backslash in the tree path makes nvim fail first, and the script exits 2 with nvim wrote no lock file in 10 s on both versions. A newline in the tree path does not: the checker refuses it with its own message (exit 2, both versions).
• The token in an exception of Node: a lock file that is valid JSON whose token holds a line break makes the WebSocket constructor throw a message that quotes the header value. The previous head printed 26 eight-character runs of such a value on stderr (my mutant's value has 33 characters, one more than a real token of 32 characters, which has 25 such runs). This head exits 2 with stopped by an unexpected TypeError, 0 runs on stdout and stderr, on both versions.
• A cd into the new temp dir that fails (a stand-in mktemp that prints a dir that does not exist, or a dir with mode 000): this head names the dir that mktemp printed in both cases, and leaves 0 dirs. The previous head named an empty path in both, and left 1 dir in the mode 000 case.
• A HUP, TERM or INT that came just after the checker exited could hang the launcher in its cleanup, with nvim and its lock file alive until the launcher was killed (wait <pid> blocked on a child that was already gone: 3 hangs in 118 signals sent right after the COUNT line, all three HUP on 0.12.3). The cleanup no longer calls wait. My 100 TERM trials on 0.8.0, each right after the COUNT line, hung 0 times (my log keeps no exit code, so it does not show that the trap ran in each one, and I count none of my HUP or INT trials after the change). Two independent verifier runs on this head: 0 hangs in 130 and in 120 signals. With wait back in the cleanup: 1 hang in 130 and 1 in 60. I did not find the cause inside bash.
• A server that died in the middle of a run could print WebSocket handshake failed. The checker now drops that handler when the connection opens, and prints the server closed the connection on both versions (SIGKILL of nvim, exit 2, no process left, no temp dir).
• The same runs on this head as before: green three times on each version with cases=44 failed=0 leaks=0 and byte-identical outputs, red proof failed=30 leaks=15 on both, wrapper without exec exit 2 and with exec pass (3 runs each, both versions), SIGKILL of the script (5 runs on each version, 0.41 s at most), 12 signal trials (TERM, INT and HUP, each between the lock file and the end of the run and right after the COUNT line, both versions: exit 143, 130, 129 or 0, no process, no temp dir left).

Findings of rounds 1 and 2 and their proofs (copies, not committed):

• Round 2, the leak rule reads the text of each frame as the wire sent it. A leaking value behind a key collision (mutant mE: one key is the work folder path and holds /virtual/probe.lua:42, one key is $CWD and holds safe): failed=41 leaks=41 on both versions, and the previous head printed failed=0 leaks=0. A duplicate key in the text item of a correct result (the real home path in the first, so the parser keeps the last): failed=2 leaks=2, and the previous head passed on both versions. A path in a JSON fragment inside a plain string (the slashes are \/ on Neovim 0.8): failed=31 leaks=31 on both versions, and the previous head passed on 0.8. The sibling-field, object-key, nested-array and late-frame mutants of round 1 stay red (failed=2 leaks=2 for the first three, failed=1 leaks=2 for the late frame).
• Round 2, a server frame that is x followed by the token (not JSON): exit 2 and one fixed message, and 0 matches of any 8-character run of the token on stdout and stderr, on both versions. The previous head printed 2 such matches on stderr. A lock file whose token value is not valid JSON, with a made-up value (not a token): 0 matches of any 8-character run of the value on stdout and stderr, and 3 on the previous head. The token in an error answer (mutant mT: the token as a field t of every -32602 error object): failed=41 leaks=41 and 0 matches.
• Round 2, a wrapper that runs Neovim without exec (VCN_NVIM is a script that runs the real binary as a child): three runs on each version exit 2 with the message, print no ok: line, and leave no process and no temp dir. A wrapper with exec: three runs on each version pass with cases=44 failed=0 leaks=0.
• Round 2, a leak in the answer of the last case: failed=1 leaks=1 and one FAIL line, where the previous head printed failed=2 and a second line for the same frame. A failing mktemp or mkdir: exit 2 and a message, where the previous head exited 1.

Round 1:

• A path in a sibling field of a correct result (result.debugPath = "/virtual/probe.lua:42"): failed=2 leaks=2 on both versions. Before, the probe printed leaks=0 and exit 0. The tree path as an object key of an answer: failed=2 leaks=2, and the same mutant passes when the checker does not rewrite keys. An extra server frame 100 ms after each valid answer, which only the read after the last case sees: failed=1 leaks=2.
• The auth token in an error answer: failed=31 leaks=31, no FAIL line printed the token, and the match count of the token in stdout, stderr and nvim's output file is 0.
• SIGKILL of the script after the checker connected: five runs on each Neovim version, both processes (recorded by PID) gone after 0.2 to 0.4 s, lock file gone after 0.2 to 0.4 s, 0 files with the token in the folder. The launcher of round 1, same test: both processes still up after 5 s, the lock file still there, 1 file with the token. A server killed in the middle of a run ends the checker with exit 2 and one message.
• An empty table: exit 2, one message, no COUNT line. A loop that judges no case, or skips one row: exit 2, no COUNT line.
• A version-manager shim as VCN_NVIM: exit 2 and a message that names it and says to set VCN_NVIM to a real binary. A node that does not start: exit 2 and a message that names it. A tree whose require fails: the last lines of nvim's output and exit 2. In a fresh clone of the branch on this host, which mise does not trust, the page's commands failed with exit 2 and that message until VCN_NVIM named a real binary. With it, the whole proof exits 0, the red proof exits 1 with failed=30 leaks=15, and the Neovim 0.8 run prints the same lines as the 0.12.3 run.
• The real home path in an answer, with the caller's HOME=/tmp: failed=31 leaks=31. The previous head printed failed=0 leaks=0 there. A module named in the caller's NODE_OPTIONS ran inside the checker of the previous head (1 marker line) and does not run now (0).
• nvim's own temp root: in a fresh /tmp (a private tmpfs), the previous head left /tmp/nvim.coder and this head leaves nothing, on both versions.

Controls that must go red (copies, not committed): main with the entry error holding the tree path, or the real home path: failed=31 leaks=31 each. The checker without the $CWD rewrite: failed=2 leaks=0. A checker whose home folder is /tmp, so that the run dir lies under it: with the $CWD rewrite first it prints failed=0 leaks=0, and with the $CWD rewrite after the $HOME one failed=2 leaks=2. A wrong expected rootPath: failed=2. A wrong named parameter for filePath: failed=8.

Other checks:

• Token: match counts of the token in stdout, stderr and nvim's output file, and in the command line and environment of the child processes: 0 each. The token has 32 characters, and none of it was printed.
• A claude on the stripped PATH (a stand-in that writes a marker file): exit 2, the marker was never written, no temp dir was made.
• TERM, INT and HUP, each sent between the lock file and the end of the run and right after the COUNT line, left no process and no temp dir (12 trials, see round 3). The cleanup ignores TERM, INT and HUP while it runs.
• Missing tree, a tree without lua/claudecode, a missing nvim, an nvim that exits at once, and a tree whose require fails: exit 2 with a message each.
• Node 22.23.4 and 26.12.1 both ran the whole probe on this head (pass on both Neovim versions, and failed=30 leaks=15 on the red tree with Node 22).
• Local merges of this head with feat(skills): add verify-mention-queue, a TLA+ model of the @mention queue #523 (eb16b3aa), docs(skills): stop telling callers to source run.env, and make the bare-tool self-check strict #508 (17252700), fix(skills): check the state dir once, not each run.env, and resolve TMPDIR once #506 (ab9d431c) and fix(diff): end diff mode in windows that show the file after a split diff closes #494 (c219b155), never pushed: no file of this PR changes, and each ran cases=44 failed=0 leaks=0 on both versions. fix(diff): hold diff teardowns behind the shared window gate #511 (ef610b7d) and fix(diff): close a new-tab diff without entering its tab #485 (d00e1be2) conflict with current main in covered.lock on their own, and their trees do not hold fix(tools): check a tools/call once and answer a malformed one with -32602 #500 (the probe prints failed=30 leaks=15 on them), so a merge check says nothing about these three files. Neither changes a path of this PR.
• A fresh clone of this head, the page's commands word for word: the whole proof exits 0 with failed=0 leaks=0, the red proof exits 1 with failed=30 leaks=15, and Neovim 0.8 prints the same line. Without VCN_NVIM the clone (which mise does not trust) exits 2 and names the shim.

Gates on this head: mise run format-check 351 files 0 changed, mise run check 0 warnings / 0 errors in 176 files, mise run test native exit 0 with 1586 successes / 0 failures / 0 errors / 22 pending (seed 1794431103), and bash .agents/skills/verify-diff-lifecycle/check.sh --hash-only prints covered.lock matches the code.

Limits

• Only getWorkspaceFolders and openFile are in the table. The feature page says so.
• The run dir is /tmp/wire-probe.XXXXXX. The probe ignores TMPDIR.
• vcn.sh has the same bin() and then env -i start for nvim, so a version-manager shim fails there too. This PR does not change vcn.sh, because fix(skills): check the state dir once, not each run.env, and resolve TMPDIR once #506 rewrites it.
• A frame that comes more than 200 ms after the last answer is not read.
• The probe has no CI job. It needs nvim and Node, and CI runs neither the harness nor this probe.

---

Generated with xum • Model: anthropic:claude-sonnet-5-5 • Thinking: xhigh

[ThomasK33]

@codex review

[ThomasK33]

@codex security review

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

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

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-11T21:24:04.118067Z	407fafb	Manual request
🔒 Security Review	✅ Completed 2026-11-11T21:24:48.735460Z	407fafb	Manual request

ℹ️ 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.

[chatgpt-codex-connector]

🛡️ Codex Security Review

Security review completed. No security issues were found in this pull request.

Reviewed commit: 44bd194528

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 44bd194528

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ThomasK33]

@codex review

[ThomasK33]

@codex security review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep it up!

Reviewed commit: f51a7f497d

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

🛡️ Codex Security Review

Security review completed. No security issues were found in this pull request.

Reviewed commit: f51a7f497d

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[ThomasK33]

@codex review

[ThomasK33]

@codex security review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. What shall we delve into next?

Reviewed commit: 7296b29171

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

🛡️ Codex Security Review

Security review completed. No security issues were found in this pull request.

Reviewed commit: 7296b29171

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[ThomasK33]

@codex review

[ThomasK33]

@codex security review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit: 407fafb700

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

🛡️ Codex Security Review

Security review completed. No security issues were found in this pull request.

Reviewed commit: 407fafb700

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.