claude-code: render a 660 s timeout for the mesh console, so mesh_wait is not cut at a minute (issue 1871) #533

2026-10-28T02:55:00Z

mesh-tools commented

2026-10-28 02:55:00 +00:00

Fixes the cut half of issue 1871. A mesh_wait through the mesh MCP server ended at about 60 s whatever timeout it was given. The console waits the full time: a direct POST of a 90 s wait answered at 90 s. The cut comes from Claude Code's documented limits for an HTTP MCP server (code.claude.com/docs/en/mcp.md, env-vars.md). A per-request timer runs until the first response byte and is at least 60 s, raised by the server entry's timeout field. An idle limit of 5 minutes (CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT) also applies.

The claude-code module now renders these for every session on every node:

in managed-mcp.json, "timeout": 660000 on the mesh entry: the console's longest wait (600 s, WaitLongest) plus a minute. No mesh_call comes near it, because the console bounds a bus request at 30 s;
in managed-settings.json, env.CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT = "660000", merged into the operator's env, with the mesh's key winning.

Quick or thorough (rule quick-or-thorough):

quick: cap mesh_wait at 55 s and let sessions loop;
thorough (chosen): the module renders the client's limits once, for every session on every node. This is the second meeting of the fault (2026-10-23 and 2026-10-28), and it hid two Approve waits.
A streaming answer in the console (mesh-tools fix/1871-wait-returns-early) was built and then dropped: the docs say the limit is set by the entry's timeout field.

Checks: the module's unit tests, go vet, go vet -tags integration, gofmt, and the catalogue's checks/ against the trunk all pass. 200 unit tests in the module (budget 500). No version bump, as before.

Live proof after delivery: restart a session, then run a 120 s mesh_wait, which must time out at 120 s and not at 60 s. Still open on 1871: try events not granted to mesh_wait.

Reviewed-by: review-1871@shanks at ae96afcaa8

Fixes the cut half of issue 1871. A `mesh_wait` through the mesh MCP server ended at about 60 s whatever timeout it was given. The console waits the full time: a direct POST of a 90 s wait answered at 90 s. The cut comes from Claude Code's documented limits for an HTTP MCP server (code.claude.com/docs/en/mcp.md, env-vars.md). A per-request timer runs until the first response byte and is at least 60 s, raised by the server entry's `timeout` field. An idle limit of 5 minutes (`CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT`) also applies. The claude-code module now renders these for every session on every node: - in `managed-mcp.json`, `"timeout": 660000` on the `mesh` entry: the console's longest wait (600 s, `WaitLongest`) plus a minute. No `mesh_call` comes near it, because the console bounds a bus request at 30 s; - in `managed-settings.json`, `env.CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT = "660000"`, merged into the operator's env, with the mesh's key winning. Quick or thorough (rule quick-or-thorough): - quick: cap `mesh_wait` at 55 s and let sessions loop; - thorough (chosen): the module renders the client's limits once, for every session on every node. This is the second meeting of the fault (2026-10-23 and 2026-10-28), and it hid two Approve waits. - A streaming answer in the console (mesh-tools fix/1871-wait-returns-early) was built and then dropped: the docs say the limit is set by the entry's timeout field. Checks: the module's unit tests, `go vet`, `go vet -tags integration`, gofmt, and the catalogue's checks/ against the trunk all pass. 200 unit tests in the module (budget 500). No version bump, as before. Live proof after delivery: restart a session, then run a 120 s `mesh_wait`, which must time out at 120 s and not at 60 s. Still open on 1871: try events not granted to `mesh_wait`. Reviewed-by: review-1871@shanks at ae96afcaa8dae6400993f5990e8ae6e07d3ba178

mesh-tools added 1 commit 2026-10-28 02:55:01 +00:00

Render a 660 s timeout for the mesh console and the MCP idle bound, so mesh_wait is not cut at a minute (issue 1871)

mesh/delivery merged: source.main moved to novox/mesh-catalog@3fb7951524e6

Details

mesh/check being carried to ae96afcaa8da on 3fb7951524e6 | from 0c63b4c906c6

ae96afcaa8

mesh-tools commented

2026-10-28 02:55:05 +00:00

Delivery novox/mesh-catalog@ae96afcaa8da — merged since 2026-10-28T07:46:29Z

Source — source.main moved to novox/mesh-catalog@3fb7951524. Whether it reached the machines is mesh-delivery-view's, derived from source.main, the wants and the haves.

Transitions

2026-10-28 02:55 (new) → proposed (announced): novox/mesh-catalog#533's head announced
2026-10-28 02:55 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail; or the check gates no merge (check-gates-merge false)
2026-10-28 07:46 ready → merged (merged): on the trunk its modules follow: merged there

The commit's note under refs/notes/mesh-plan keeps every transition of this change up to its merge: git log --notes=mesh-plan.

**Delivery** `novox/mesh-catalog@ae96afcaa8da` — **merged** since 2026-10-28T07:46:29Z **Source** — source.main moved to novox/mesh-catalog@3fb7951524e6. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves. **Transitions** - 2026-10-28 02:55 (new) → proposed (announced): novox/mesh-catalog#533's head announced - 2026-10-28 02:55 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail; or the check gates no merge (check-gates-merge false) - 2026-10-28 07:46 ready → merged (merged): on the trunk its modules follow: merged there The commit's note under `refs/notes/mesh-plan` keeps every transition of this change up to its merge: `git log --notes=mesh-plan`.

mesh-tools merged commit 3fb7951524 into main

2026-10-28 07:46:26 +00:00

mesh-tools deleted branch fix/1871-wait-returns-early

2026-10-28 07:46:27 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-catalog#533