[rennf93]

Four changes that make murmur cheaper and less misleading for the agents that use it. Each one comes from something that cost a turn or tokens in today's sessions. Two commits.

What changed

1. Replies handed over in a wait no longer count as unread. A reply returned inside a murmur_wait result now ends acknowledged instead of delivered (takeReplies calls store.markAcked after markDeliveredHop). Before, delivered stayed in the unread states forever: my session on the real bus shows unread 4, and all four (messages 5, 7, 9 and 10) are replies it already received in wait results. The No queued_delivered note for a reply handed over in the wait #14 behaviour (no queued_delivered notice for those) is unchanged, and the inbox cap still counts only queued and sent.
2. Default wait is 110 s instead of 120 s. WAIT_DEFAULT_MS was 120000, the same as Claude Code's default auto-background threshold for MCP calls (CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS). A full default wait got moved to the background and its result came back as a separate notification, an extra turn (about 38k tokens a call in the consult benchmark). The max stays 300 s. MCP description, both adapters, docs and README updated; docs/consult.md explains the 120 s threshold.
3. The per-message footer drops the shell route for sessions that have murmur tools. The footer said from a shell: murmur reply <id> <text>. In 3 of 4 Codex runs before 0.2.5, the model took that route and hit Codex's sandbox (Ran murmur reply 1 'INFO received', then "broker is down"). Now the clause is left out when the recipient has a live mcp or adapter connection (the broker's presence map, which holds only live connections); a session without tools keeps it. All three render paths pass the flag (core pushesFor, core pending push, broker pushQueued).
4. murmur_thread without threadId lists the newest threads. Today an agent can't find the active thread with murmur's tools: every tool needs a thread id, and I had to query the SQLite file directly to find thread 17. A new threads request returns, newest activity first, threadId, latestSeq, lastAt, participants, messages and the opening message's first line; limit defaults to 10, max 50. No ninth tool (every tool schema sits in every session's context). CLI murmur thread with no id and both adapters match.

Issue

No issue filed. From a review of my own use of murmur today.

How it was verified

• Tests first for each change. Verbatim failures on master: expected [ [ 'alice', 'delivered' ] ] to deeply equal [ [ 'alice', 'acknowledged' ] ], expected 120000 to be 110000, the footer test receiving the old text with from a shell: murmur reply 7 <text>;, and MurmurError: unknown message type: threads / TypeError: core.threadList is not a function.
• npm run build, then npm run coverage on the combined branch: Tests 518 passed (518), 100 percent on statements (2357/2357), branches (1327/1327), functions (438/438) and lines (2277/2277). tsc --noEmit exit 0, markdownlint 0 issues, typos exit 0, no em or en dashes in the diff.
• Live, two real Claude Code sessions (haiku) on this branch's murmur in an isolated rig: X asked Y with murmur_send and wait: all_replied, then called murmur_thread with no id.
  • PASS Y replied through murmur_reply: {"sender":"claude-murmur-2","body":"INFO 5"}
  • PASS the reply X got inside its wait is acknowledged, not delivered (no longer unread): [{"recipient":"claude-murmur","state":"acknowledged"}]
  • PASS Y (a session with the MCP tools) saw the footer without the shell route: (answer with murmur_reply messageId 1, plain text never reaches the sender; its replies: murmur_thread 1 messageId 1)
  • X's pane: "murmur_thread with no threadId listed one thread: Thread 1, 2 messages, latest seq 1, Participants: claude-murmur and claude-murmur-2, First message: ..."
  • RESULT: PASS
• store.threadList(10) over 100k messages in 2000 threads: median 10.2 ms, max 12.2 ms (7 runs).
• An independent review confirmed all six claims. Its caveats: the wait handover marks acknowledged without the onStateChange event core.ack emits, which nothing consumes today (the only implementation is a no-op in src/cli.ts); and the thread listing scans the messages table on every call, which the timing above puts at about 10 ms for 100k messages.
• Not run: live checks through Codex, hummin and opencode for the footer change.

Behavior changes

• Replies returned in a wait end acknowledged, not delivered. The existing four delivered rows on a bus stay as they are.
• murmur_wait defaults to 110 s.
• Sessions with murmur tools no longer see the shell route in the footer.
• murmur_thread takes an optional threadId and a new limit; murmur thread with no id lists threads instead of failing.