feat(mcp): pass through the Reasonix per-server startup_timeout_seconds - #2620
Merged
Merged
Conversation
REASONIX_PLUGIN_FIELDS is a strict allowlist, and rulesync owns the plugins key wholesale, so a hand-written startup_timeout_seconds was dropped on the next generate. Reasonix documents it as a per-server override of the global mcp_startup_timeout_seconds, with 0 meaning defer to that cap, so it now round-trips as a passthrough field alongside call_timeout_seconds and tool_timeout_seconds. Also correct two stale claims that the exact Bash=<literal> form is the only way to pre-authorize dynamic or nested Bash in a headless run short of YOLO: v1.19.0 added the allow_dynamic_bash opt-in. Authoring it through rulesync remains unsupported.
…rkTimeout Canonical networkTimeout does cover the same startup phase - Codex CLI deep-maps it to startup_timeout_sec - so claiming no canonical equivalent was wrong. The reason for passing through is the mismatch: canonical timeouts are milliseconds against Reasonix's seconds, and Reasonix's meaningful 0 has no canonical spelling. Vibe passes its own startup_timeout_sec through for the same reason. Also cover the 0 case on the export side, and narrow the Bash wording to nested or indirect execution, which is the class SPEC 3.7 actually gates behind a literal grant.
This was referenced Aug 7, 2026
Merged
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
REASONIX_PLUGIN_FIELDSis a strict allowlist and rulesync owns thepluginskey wholesale, so a hand-writtenstartup_timeout_secondswas silently dropped on the next generate. It now round-trips as a passthrough field alongsidecall_timeout_secondsandtool_timeout_seconds.Reasonix documents it as a per-server override of the global
mcp_startup_timeout_seconds, capping the background launch/authorization/initialize/tools/listsequence, with0meaning defer to that global cap. A test covers the0case specifically, since a falsy-but-meaningful value is the easy thing to drop.Also in this PR
Two stale prose spots claimed the exact
Bash=<literal>form is "the only way to pre-authorize dynamic or nested Bash in headlessreasonix runshort of YOLO" -docs/reference/file-formats.mdand therawAllowcomment insrc/types/permissions.ts. That stopped being true in v1.19.0, which added the blanket[permissions] allow_dynamic_bashopt-in (SPEC: "lets an Allow fallback, including Auto, cover this class; explicitaskanddenyrules retain precedence"). Both now mention it exists, while stating that authoring it through rulesync is unsupported.Verified against SPEC.md:
# startup_timeout_seconds = 60 # initialize + tools/list cap; 0 = global/default cap. Checked locally with the MCP e2e spec.Part of #2599
Gaps 2 (the
allow_dynamic_bashauthoring shape) and 3 (the hookcwdcanonical field) are design items and remain open.🤖 Generated with Claude Code