fix(agent-core): correct v1 Agent tool description to say fixed 2-hour timeout#1875
fix(agent-core): correct v1 Agent tool description to say fixed 2-hour timeout#1875C0d3N1nja97342 wants to merge 2 commits into
Conversation
…r timeout The v1 engine's Agent tool description told the model "subagents use a fixed 30-minute timeout", but the actual default has been 2 hours since v0.23.6 (MoonshotAI#1562) and was aligned across engines in v0.24.2 (MoonshotAI#1704). The v2 tool description was updated at the time; the v1 copy was missed and the test assertion in packages/agent-core/test/tools/agent.test.ts:131 enshrined the stale string, so the drift went unnoticed. Since the interactive CLI defaults to the v1 engine, this stale text is what most sessions injected into model context. Actual timeout enforcement was already 2 hours (DEFAULT_SUBAGENT_TIMEOUT_MS in subagent-host.ts) — only the LLM-facing description was wrong. Update: - packages/agent-core/src/tools/builtin/collaboration/agent.md:12 — "fixed 30-minute" → "fixed 2-hour" (matches v2's agent.md). - packages/agent-core/src/session/subagent-host.ts:41 — the JSDoc still said "(30 min)", update to "(2 hours)". - packages/agent-core/test/tools/agent.test.ts:131 — assertion updated. Fixes MoonshotAI#1817
🦋 Changeset detectedLatest commit: 3865026 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f9945eeb40
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| - When the task continues earlier work a subagent already did, prefer resuming that agent (pass its `resume` id) over spawning a fresh instance — the resumed agent keeps its prior context. | ||
| - A subagent's result is only visible to you, not to the user. When the user needs to see what a subagent produced, summarize the relevant parts yourself in your own reply. | ||
| - Subagents use a fixed 30-minute timeout. If one times out, resume the same agent instead of starting over. | ||
| - Subagents use a fixed 2-hour timeout. If one times out, resume the same agent instead of starting over. |
There was a problem hiding this comment.
When subagent.timeoutMs or KIMI_SUBAGENT_TIMEOUT_MS is set to 30 minutes, the runtime still passes that resolved value to AgentTool in packages/agent-core/src/agent/tool/index.ts, but this changed description now tells the model that the timeout is fixed at two hours. That configuration was described correctly before this change, so the model may now launch work expecting four times the available runtime; build the description from the resolved subagentTimeoutMs (using the existing formatter) rather than embedding the default.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
This is a real distinction, but I don't think the fix is in scope for this PR — the same asymmetry already lives in v2 today.
The pre-existing "fixed 30-minute" wording was also wrong under a config override — it just happened to be wrong in a specific direction (understating). Whether the description hard-codes 30-minute or 2-hour, any override drifts it out of sync with runtime; that failure mode isn't new.
packages/agent-core-v2/src/session/subagent/tools/agent.md:12 uses the same static "fixed 2-hour timeout" wording and the v2 test at packages/agent-core-v2/test/tool/tool.test.ts:454 asserts it verbatim. So making v1 dynamic here creates a new v1/v2 asymmetry — the same drift-under-override still applies to v2 sessions, just not visibly. #1817 was filed specifically against v1, and the reporter's primary ask is aligning v1 with v2; dynamic rendering was flagged as "or better", i.e. an optional larger refactor.
The right place for dynamic rendering is a follow-up PR that lands the change in both engines together (via formatSubagentTimeoutDescription(resolveSubagentTimeoutMs(...)) inside the description-composition path in agent.ts, mirrored across agent-core-v2). Happy to open that as a separate issue if maintainers want to prioritize it. Keeping this PR at the byte-for-byte alignment scope the issue asked for.
…escription-timeout # Conflicts: # packages/agent-core/src/session/subagent-host.ts
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3865026107
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| - When the task continues earlier work a subagent already did, prefer resuming that agent (pass its `resume` id) over spawning a fresh instance — the resumed agent keeps its prior context. | ||
| - A subagent's result is only visible to you, not to the user. When the user needs to see what a subagent produced, summarize the relevant parts yourself in your own reply. | ||
| - Subagents use a fixed 30-minute timeout. If one times out, resume the same agent instead of starting over. | ||
| - Subagents use a fixed 2-hour timeout. If one times out, resume the same agent instead of starting over. |
There was a problem hiding this comment.
When v1 runs in print mode or with subagent.timeoutMs/KIMI_SUBAGENT_TIMEOUT_MS configured, this description contradicts runtime behavior: agent/tool/index.ts:758 passes the resolved value to AgentTool, and config/print-defaults.ts:19-24 explicitly sets it to 0 (no timeout) for kimi -p. The model will nevertheless be told that every subagent has a fixed two-hour deadline, so this should be rendered from the effective timeout, including the no-timeout case, rather than hard-coded.
Useful? React with 👍 / 👎.
1 participant
Related Issue
Resolves #1817
Problem
See linked issue. Summary: the v1 engine's
Agenttool description tells the model that subagents use "a fixed 30-minute timeout", but the actual default has been 2 hours since v0.23.6 (#1562) and was aligned across engines in v0.24.2 (#1704). The v2 tool description was updated at the time (packages/agent-core-v2/src/session/subagent/tools/agent.md:12reads "fixed 2-hour timeout" andagent-core-v2/test/tool/tool.test.ts:454asserts it), but the v1 copy was missed and the assertion inpackages/agent-core/test/tools/agent.test.ts:131enshrined the stale string, so the drift went unnoticed. Because the interactive CLI defaults to the v1 engine, this stale text is what most sessions injected into the model's context. Actual timeout enforcement was already correct at 2 hours; only the LLM-facing description was wrong.What changed
Three tiny string updates to align the v1 description with the v2 one and with the actual runtime default:
packages/agent-core/src/tools/builtin/collaboration/agent.md:12— "fixed 30-minute timeout" → "fixed 2-hour timeout". This markdown file is embedded verbatim into the tool description via?rawimport inagent.ts, so every v1-engine session now sees the correct wording.packages/agent-core/src/session/subagent-host.ts:41— the JSDoc onresolveSubagentTimeoutMsstill parenthetically said "(30 min)"; corrected to "(2 hours)" so a future reader isn't misled by the internal comment either.packages/agent-core/test/tools/agent.test.ts:131— the assertion that pinned the stale wording is updated to match the new description, so the drift can no longer recur silently.I deliberately kept the change to a byte-for-byte alignment with v2 rather than switching the description to dynamic rendering via
formatSubagentTimeoutDescription(resolveSubagentTimeoutMs(...)). The issue author flagged dynamic rendering as a "better" option, but v2 itself uses the same static-string approach, so making v1 dynamic would create a new asymmetry between engines. If dynamic rendering is desired, it should land in both engines at once and is out of scope for this fix.Checklist
gen-changesetsskill, or this PR needs no changeset. — added.changeset/fix-v1-agent-tool-description-timeout.md(patch on@moonshot-ai/kimi-code, since the change surfaces to CLI users via the model context).gen-docsskill, or this PR needs no doc update. — the touched string is the tool description consumed by the model; no user-facingdocs/page mentions the 30-minute wording, so no doc changes needed.