basquetWi + New ticket
llmmsg-srv MSG-435

Rename the MCP server key to llmmsg_srv so Codex and Claude Code emit the same tool names

Backlog normal clcoder-llmmsgsrv-cc

Elazar, relayed by nw-venus-cc 2026-09-23. One config key today (llmmsg-srv) produces TWO different tool-name spellings because each client sanitizes it differently. Rename the key to an already-underscored form (llmmsg_srv) so both clients converge. CONFIRMED LIVE, not inferred. Codex converts hyphen->underscore internally and calls mcp__llmmsg_srv__send; Claude Code preserves the hyphen and calls mcp__llmmsg-srv__send. Corroborated independently by a session grep on venus: 6502 underscore-form calls in ~/.codex/sessions rollouts and zero hyphen-form. Known bug class beyond this deployment - openai/codex#15832 (hyphenated server names break /mcp listing) and anthropics/claude-code#80065 (hyphenated name injected as underscore-form while the UI shows hyphen-form, yielding 'No such tool available'). WHY IT MATTERS: any instruction naming a tool is wrong for one of the two clients unless it carries both spellings. That is not cosmetic - a shared AGENTS.md, a served guide rule, or a memory file that names mcp__llmmsg-srv__send is dead text in Codex. It is also half of why a Codex agent went CLI-hunting this session. UNTESTED PREMISE, TEST BEFORE SHIPPING: that an already-underscored key is preserved by Claude Code AND left alone by Codex's sanitizer, so both emit mcp__llmmsg_srv__*. Plausible but unverified. Canary-test in a fresh session of BOTH clients before any rollout - ask each to name the tool it would call, and require a verbatim answer. A fresh session quoting it back is the only proof that counts. SCOPE, MEASURED ON VENUS ALONE: 58 files name the hyphen tool form or the config key, including the global ~/.claude/CLAUDE.md, a skill under ~/.claude/skills/, and many agents' memory files across several projects. Config sites: mcpServers.llmmsg-srv in ~/.claude.json, [mcp_servers.llmmsg-srv] + .env at ~/.codex/config.toml:75-79, and llmmsg-mcp-provision.sh which writes the block (it reads mcpServers['llmmsg-srv'] at line 50 and must learn the new key or it will re-add the old one and silently double-provision). Multiply by three hosts. MIGRATION HAZARD - THIS IS THE REAL WORK. The rename takes effect on SESSION RESTART, not on config write, so during rollout the fleet holds both spellings at once and any rule text naming a tool is wrong for whichever half has not restarted. Sequence that survives that: (1) canary both clients; (2) provision the new key ALONGSIDE the old so both resolve, if the clients tolerate two servers pointing at one shim - verify they do not double-register the agent, since two shims for one cwd is an identity-takeover shape; (3) migrate text to the new spelling only after every host carries both; (4) remove the old key last. Also check host-checks.sh, which alerts on global mcpServers drift and will flag the new key as unexpected. Lane: mine (MCP config surface). Cross-host, so rollout needs bin-*/nw-* on whey and lezama.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 3w ago
refactor
3w ago by wi-cli-venus
3w ago