fix(core): reject run_in_background: false for named teammates - #9433
Merged
Conversation
A named Agent Team teammate accepted run_in_background: false but silently ignored it: the teammate route runs before the regular foreground/background classification and always returns right after spawn, so the flag had no effect. A structured local run showed five named teammates spawned concurrently — including two launched with an explicit false — each continuing to consume model tokens while the accepted flag said not to background the launch. Named teammates are inherently concurrent (persistent team identity, messaging, automatic final-report delivery), so foreground semantics cannot apply. Make the incompatible combination hard to generate and impossible to spawn: - Tool prose: the team guidance, the name property, and the run_in_background schema description now state that teammates always run concurrently, that callers should omit run_in_background, and that an inline blocking result requires omitting name and using a regular agent with run_in_background: false. - validateToolParams rejects run_in_background: false when name routes to an active team, before any spawn. Without an active team the name falls through to a regular agent, where the foreground request stays valid. - The execute-time team-routing branch carries the same rejection as defense in depth, mirroring the existing model/isolation blocks. Fixes #9430
yiliang114
requested review from
LaZzyMan,
doudouOUC,
tanzhenxin and
wenshao
as code owners
August 18, 2026 21:06
Collaborator
qwen-code-ci-bot
requested changes
Aug 18, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Thanks @yiliang114 — the underlying problem is real and well evidenced (see #9430: five named teammates spawned, and the two launched with run_in_background: false kept running and consuming tokens after the flag said not to background them). Before this moves to code review, one housekeeping item: the PR body doesn't use the repository's pull request template.
Merged PRs here follow that template consistently, and reviewers rely on the fixed sections to find what they need. The body is missing all of the required headings:
## What this PR does## Why it's needed## Reviewer Test Plan(with### How to verify,### Evidence (Before & After), and the### Tested onOS table)## Risk & Scope## Linked Issues- the Chinese translation inside
<details>— the template asks for the full body to be mirrored in Chinese
Nearly everything is already written in the current body — the what/why prose, the vitest verification with the four new cases, Fixes #9430 — so this should be a reformat rather than a rewrite. Please restructure it into the template sections: https://github.com/QwenLM/qwen-code/blob/main/.github/pull_request_template.md
One note while you're at it: the Tested on table wants ✅ /
Once the body follows the template, a re-run (@qwen-code /triage) will pick it up and continue the review. 🙏
中文说明
感谢 @yiliang114 —— 底层问题真实存在且证据充分（见 #9430：五个具名 teammate 被启动，其中两个以 run_in_background: false 启动的 teammate 在参数明确要求不后台运行后仍继续执行并消耗 token）。在进入代码审查之前，有一个流程问题：这个 PR 的正文没有使用本仓库的 pull request 模板。
本仓库已合并的 PR 都遵循该模板，reviewer 依赖这些固定章节来快速定位所需信息。当前正文缺少全部必需章节：
## What this PR does## Why it's needed## Reviewer Test Plan（含### How to verify、### Evidence (Before & After)以及### Tested on操作系统表格）## Risk & Scope## Linked Issues<details>中的中文翻译——模板要求将正文完整翻译为中文
其实所需内容在现有正文里都已经写到了——改动与动机描述、vitest 验证及四个新用例、Fixes #9430——所以只需重新排版，不必重写。请按模板章节重新组织：https://github.com/QwenLM/qwen-code/blob/main/.github/pull_request_template.md
另外提醒一点：Tested on 表格需要按操作系统标注 ✅ /
正文符合模板后，重新触发（@qwen-code /triage）即可继续审查。🙏
— Qwen Code · qwen3.8-max
Contributor
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Reviewed. Suggestions are inline. 1 Suggestion-level finding(s) could not be anchored to a changed line and were dropped; nothing further to act on here.
Not explored to full depth (tool budget reached): "agent 5": did not execute the test suite — the worktree has no node_modules / dist anywhere and a full npm ci + monorepo build exceeds this review's budget; pass/fail…; "agent 6b": run the new agent.test.ts cases — neither the worktree nor the parent checkout has node_modules, and npm ci (which triggers the full prepare build) does not….
— qwen3.8-max via Qwen Code /review (v0.21.13)
Comment on lines
+1169
to
+1173
| params.run_in_background === false && | ||
| params.name && | ||
| !isTeammate() && | ||
| isTopLevelSession() && | ||
| this.config.getTeamManager() |
Collaborator
There was a problem hiding this comment.
[Suggestion] This gate inlines the "would route as a named teammate" routing predicate for the third time in validateToolParams (copies already exist in the model gate at ~1024-1028 and the isolation gate at ~1113-1117), making four copies in this file counting the team-routing branch in execute (~2275-2276). No shared helper exists (agents/team/identity.ts only exposes identity primitives), and the rejection prose is repeated near-verbatim at ~1175 and ~2295 with only a Parameter/Error: prefix difference. — Concrete cost: the gate's own comment states it "mirrors the team-routing branch in execute" — that sync is now maintained by hand across four sites. When teammate routing changes, every copy must be edited in lockstep; missing the new gate makes validateToolParams accept (or reject) a combination that execute routes differently — silently resurrecting the exact defect class this PR fixes.
Suggested fix: extract a private helper used in all three validation gates (the isolation gate keeps its extra working_dir === undefined clause):
private wouldSpawnAsNamedTeammate(params: AgentParams): boolean {
return !!params.name && !isTeammate() && isTopLevelSession() && !!this.config.getTeamManager();
}Optionally lift the shared rejection sentence into a module constant prefixed differently at each site.
— qwen3.8-max via Qwen Code /review (v0.21.13)
| // `team_create` tool that isn't registered. | ||
| const teamGuidance = this.config.isAgentTeamEnabled() | ||
| ? `**For tasks requiring multiple agents to coordinate, communicate, or work as a team**: Use ${ToolNames.TEAM_CREATE} first to create a team, then spawn teammates using the Agent tool with explicit \`name\` and \`subagent_type\` parameters (the active team is selected automatically). Set \`read_only: true\` for investigation teammates. A single writer teammate may be pinned to a leader-owned Git worktree with \`working_dir\`; shut it down before removing that worktree. Teams enable message passing between agents, shared task lists, and coordinated workflows. If the user asks for agents to collaborate, review each other's work, or produce a consolidated result — create a team.` | ||
| ? `**For tasks requiring multiple agents to coordinate, communicate, or work as a team**: Use ${ToolNames.TEAM_CREATE} first to create a team, then spawn teammates using the Agent tool with explicit \`name\` and \`subagent_type\` parameters (the active team is selected automatically). Named teammates always run concurrently and report through team messaging; omit \`run_in_background\` when spawning one — an explicit \`run_in_background: false\` is rejected, so for an inline blocking result omit \`name\` and use a regular agent instead. Set \`read_only: true\` for investigation teammates. A single writer teammate may be pinned to a leader-owned Git worktree with \`working_dir\`; shut it down before removing that worktree. Teams enable message passing between agents, shared task lists, and coordinated workflows. If the user asks for agents to collaborate, review each other's work, or produce a consolidated result — create a team.` |
Collaborator
There was a problem hiding this comment.
[Suggestion] This inline-result remedy omits run_in_background: false, which all three sibling surfaces include (TEAM_AGENT_NAME_PROPERTY: "use a regular agent with run_in_background: false instead"; the run_in_background schema description: "run a regular agent with run_in_background: false"; both rejection messages: "keep run_in_background: false"). — Failure scenario: teams enabled; the model wants an inline blocking result, follows this sentence, omits name and also omits the flag. Top-level regular agents resolve run_in_background to true when the flag is omitted (default-resolution at ~2640-2651), so the agent launches in the background and the turn ends without an inline result — the exact caller-expects-inline confusion this PR eliminates.
Suggested fix: end the sentence with
so for an inline blocking result omit `name` and use a regular agent with `run_in_background: false` instead.
— qwen3.8-max via Qwen Code /review (v0.21.13)
Comment on lines
+1169
to
+1170
| params.run_in_background === false && | ||
| params.name && |
Collaborator
There was a problem hiding this comment.
[Suggestion] No acceptance test covers run_in_background: false without name while a team is active, so the params.name && condition that keeps this gate from firing on regular foreground agents is unguarded — every validateToolParams test that enables the team manager also sets name, and every unnamed run_in_background: false test runs against the default no-team config. — Failure scenario (mutation-tested): deleting params.name && leaves the whole suite green while rejecting every regular top-level foreground agent launch made while a team is active — an inline run_in_background: false delegation would fail validation with the teammate-specific error, breaking exactly the working foreground path this gate's own comment says must stay valid.
Witness: mutation probe in the PR worktree — deleting params.name && → suite still Tests 262 passed (262) (mutation survives); with the proposed test added → × PROBE f4: accepts run_in_background: false without a name when a team is active (mutation caught); restored code with probe → Tests 264 passed (264).
Suggested fix: add a validation test — mock config.getTeamManager to an active team, then
expect(
agentTool.validateToolParams({ ...validParams, run_in_background: false }),
).toBeNull();(no name).
— qwen3.8-max via Qwen Code /review (v0.21.13)
Comment on lines
+1171
to
+1172
| !isTeammate() && | ||
| isTopLevelSession() && |
Collaborator
There was a problem hiding this comment.
[Suggestion] The nested-session fall-through (name + run_in_background: false → regular foreground agent) has no validation coverage — the diff added an acceptance test for the analogous "no active team" fall-through but not for the "not top-level" fall-through this isTopLevelSession() condition permits. The existing nested test "ignores a teammate name from a nested sub-agent" bypasses validateToolParams via agentTool.build() and omits the flag, so it cannot catch this. — Failure scenario (mutation-tested): deleting isTopLevelSession() && leaves the suite green while rejecting a nested call (name + explicit run_in_background: false, team active) at validation even though execute would happily spawn a regular foreground agent — nested runs are forced foreground anyway (shouldRunInBackground = backgroundRequested && isTopLevelSession()).
Witness: mutation probe in the PR worktree — deleting isTopLevelSession() && → suite passes with probes stashed (mutation survives); with the proposed test added → × PROBE f5: accepts run_in_background: false with a name from a nested sub-agent (mutation caught); restored code with probe → Tests 264 passed (264).
Suggested fix: with the team manager mocked active,
runWithAgentContext('sub-1', () =>
expect(
agentTool.validateToolParams({
...validParams,
name: 'helper',
run_in_background: false,
}),
).toBeNull(),
);— qwen3.8-max via Qwen Code /review (v0.21.13)
Collaborator
Author
|
@qwen-code /review |
Contributor
|
Qwen Code review request accepted. Review is queued in workflow run. |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Reviewed — no blockers. Suggestions are inline.
— qwen3.8-max via Qwen Code /review (v0.21.13)
| params.name && | ||
| !isTeammate() && | ||
| isTopLevelSession() && | ||
| this.config.getTeamManager() |
Collaborator
There was a problem hiding this comment.
[Suggestion] R1-1: This gate inlines the "would route as a named teammate" routing predicate for the third time in validateToolParams (copies already exist in the model gate at ~1024-1028 and the isolation gate at ~1113-1117), making four copies in this file counting the team-routing branch in execute (~2275-2276). No shared helper exists, and the rejection prose is repeated near-verbatim at ~1175 and ~2295 with only a Parameter/Error: prefix difference. Still stands at the reviewed commit — code unchanged since round 1. — Concrete cost: the gate's own comment states it "mirrors the team-routing branch in execute" — that sync is now maintained by hand across four sites. When teammate routing changes, every copy must be edited in lockstep; missing the new gate makes validateToolParams accept (or reject) a combination that execute routes differently — silently resurrecting the exact defect class this PR fixes.
Suggested fix: extract a private helper used in all three validation gates (the isolation gate keeps its extra working_dir === undefined clause):
private wouldSpawnAsNamedTeammate(params: AgentParams): boolean {
return !!params.name && !isTeammate() && isTopLevelSession() && !!this.config.getTeamManager();
}Optionally lift the shared rejection sentence into a module constant prefixed differently at each site.
— qwen3.8-max via Qwen Code /review (v0.21.13)
| // `team_create` tool that isn't registered. | ||
| const teamGuidance = this.config.isAgentTeamEnabled() | ||
| ? `**For tasks requiring multiple agents to coordinate, communicate, or work as a team**: Use ${ToolNames.TEAM_CREATE} first to create a team, then spawn teammates using the Agent tool with explicit \`name\` and \`subagent_type\` parameters (the active team is selected automatically). Set \`read_only: true\` for investigation teammates. A single writer teammate may be pinned to a leader-owned Git worktree with \`working_dir\`; shut it down before removing that worktree. Teams enable message passing between agents, shared task lists, and coordinated workflows. If the user asks for agents to collaborate, review each other's work, or produce a consolidated result — create a team.` | ||
| ? `**For tasks requiring multiple agents to coordinate, communicate, or work as a team**: Use ${ToolNames.TEAM_CREATE} first to create a team, then spawn teammates using the Agent tool with explicit \`name\` and \`subagent_type\` parameters (the active team is selected automatically). Named teammates always run concurrently and report through team messaging; omit \`run_in_background\` when spawning one — an explicit \`run_in_background: false\` is rejected, so for an inline blocking result omit \`name\` and use a regular agent instead. Set \`read_only: true\` for investigation teammates. A single writer teammate may be pinned to a leader-owned Git worktree with \`working_dir\`; shut it down before removing that worktree. Teams enable message passing between agents, shared task lists, and coordinated workflows. If the user asks for agents to collaborate, review each other's work, or produce a consolidated result — create a team.` |
Collaborator
There was a problem hiding this comment.
[Suggestion] R1-2: This inline-result remedy omits run_in_background: false, which all three sibling surfaces include (TEAM_AGENT_NAME_PROPERTY: "use a regular agent with run_in_background: false instead"; the run_in_background schema description: "run a regular agent with run_in_background: false"; both rejection messages: "keep run_in_background: false"). Still stands at the reviewed commit — code unchanged since round 1. — Failure scenario: teams enabled; the model wants an inline blocking result, follows this sentence, omits name and also omits the flag. Top-level regular agents resolve run_in_background to true when the flag is omitted (default-resolution at ~2640-2651), so the agent launches in the background and the turn ends without an inline result — the exact caller-expects-inline confusion this PR eliminates.
Suggested fix: end the sentence with
so for an inline blocking result omit `name` and use a regular agent with `run_in_background: false` instead.
— qwen3.8-max via Qwen Code /review (v0.21.13)
| // agent, where `run_in_background: false` is a valid foreground request. | ||
| if ( | ||
| params.run_in_background === false && | ||
| params.name && |
Collaborator
There was a problem hiding this comment.
[Suggestion] R1-3: No acceptance test covers run_in_background: false without name while a team is active, so the params.name && condition that keeps this gate from firing on regular foreground agents is unguarded — every validateToolParams test that enables the team manager also sets name, and every unnamed run_in_background: false test runs against the default no-team config. Still stands at the reviewed commit — code and tests unchanged since round 1. — Failure scenario (mutation-tested in round 1): deleting params.name && leaves the whole suite green while rejecting every regular top-level foreground agent launch made while a team is active — an inline run_in_background: false delegation would fail validation with the teammate-specific error, breaking exactly the working foreground path this gate's own comment says must stay valid.
Suggested fix: add a validation test — mock config.getTeamManager to an active team, then
expect(
agentTool.validateToolParams({ ...validParams, run_in_background: false }),
).toBeNull();(no name).
— qwen3.8-max via Qwen Code /review (v0.21.13)
| params.run_in_background === false && | ||
| params.name && | ||
| !isTeammate() && | ||
| isTopLevelSession() && |
Collaborator
There was a problem hiding this comment.
[Suggestion] R1-4: The nested-session fall-through (name + run_in_background: false → regular foreground agent) has no validation coverage — the diff added an acceptance test for the analogous "no active team" fall-through but not for the "not top-level" fall-through this isTopLevelSession() condition permits. The existing nested test "ignores a teammate name from a nested sub-agent" bypasses validateToolParams via agentTool.build() and omits the flag, so it cannot catch this. Still stands at the reviewed commit — code and tests unchanged since round 1; this round's test-coverage walk also found the sibling !isTeammate() exclusion of this gate untested the same way (same bounded family). — Failure scenario (mutation-tested in round 1): deleting isTopLevelSession() && leaves the suite green while rejecting a nested call (name + explicit run_in_background: false, team active) at validation even though execute would happily spawn a regular foreground agent — nested runs are forced foreground anyway (shouldRunInBackground = backgroundRequested && isTopLevelSession()).
Suggested fix: with the team manager mocked active,
runWithAgentContext('sub-1', () =>
expect(
agentTool.validateToolParams({
...validParams,
name: 'helper',
run_in_background: false,
}),
).toBeNull(),
);— qwen3.8-max via Qwen Code /review (v0.21.13)
Collaborator
Author
|
@qwen-code /triage |
Collaborator
|
Sandboxed verification: The verification job did not complete (checkout, runner, or setup error) and produced no report. See the workflow run for details. 中文 — 判定：
|
Collaborator
|
Thanks for the PR! Template: the body still doesn't use the repository template headings, and the earlier Stage 1a gate remains on record as a Problem: observed, not theoretical. #9430 documents a structured run where five named teammates were spawned — three with Direction: aligned. An accepted-then-ignored parameter on the Agent tool is exactly the kind of contract trap that wastes launches and tokens, and rejecting it with actionable guidance is the right shape. Claude Code's CHANGELOG has no entry for this exact case, but teammate/background semantics are a live area there (several recent teammate fixes, and non-teammate spawns now default to background in interactive sessions), and the linked issue is on the Size: touches core ( Approach: scope feels right and minimal. It mirrors the existing Risk: no high-risk-path matches ( Moving on to code review. 🔍 中文说明感谢贡献！ 模板： PR 正文仍未使用仓库模板的章节标题，上一轮 Stage 1a 的 问题： 已观测到的真实问题，而非理论担忧。#9430 记录了一次结构化运行：五个具名 teammate 被启动（三个 方向： 对齐。Agent 工具上"接受却忽略"的参数正是浪费启动与 token 的合约陷阱，以可操作的指引拒绝它是正确的形态。Claude Code 的 CHANGELOG 没有完全对应的条目，但 teammate/后台语义在该处是活跃领域（近期有多项 teammate 修复，交互式会话中非 teammate 启动也默认转为后台），且关联 issue 在 规模： 触及核心路径（ 方案： 范围合理且最小化。与既有的 风险： 未命中高风险路径（ 进入代码审查。🔍 — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
Code reviewReviewed against
Two non-blocking notes (also raised by
Test evidence (the PR's own CI, via API — no PR code executed in this run)All checks settled on the reviewed commit. The Ubuntu unit suite is the PR signal: vitest reported 46053 passed / 32 skipped monorepo-wide, and
One thread item worth explaining: the auto-triggered Real-scenario (tmux) testing: N/A on this path — this is an unattended CI run, so no local product drive is attempted; the live-behavior lane is the 中文说明代码审查在
两条非阻塞备注（
测试证据（来自 PR 自身 CI，通过 API 获取——本次运行未执行任何 PR 代码）所有检查在该提交上已出结果。Ubuntu 单元测试是 PR 信号：vitest 全仓报告 46053 通过 / 32 跳过，其中 线程中有一项需要解释：本次运行自动触发的 真实场景（tmux）测试：此路径不适用——这是无人值守的 CI 运行，不进行本地产品驱动；实时行为通道即上面的 — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
|
Confidence: 5/5 — observed problem with a real reproduction, a minimal fix that reuses the established teammate-gate pattern exactly, and CI evidence that pins the change. Stepping back: this is what a good small fix looks like. The problem was real and quantified in #9430 — two teammates kept spending tokens after The two notes from the code review are cosmetic — a prose-completeness gap in one of three guidance sites, and the routing predicate now living in four places per this file's existing convention. Neither is worth holding a 36-line fix for; both are fine as follow-ups if anyone cares. One honest caveat stays on record: the suite mocks the TeamManager, so the end-to-end "a live launch refuses before spending tokens" path rests on the unit-level block sitting ahead of The earlier template gate (Stage 1a) stands as a record, but the author is a repository maintainer who re-triggered triage deliberately, and housekeeping doesn't block a re-run. LGTM, approving. ✅ 中文说明置信度：5/5 —— 问题有真实复现、修复最小化且完全复用既有的 teammate 关卡模式，CI 证据钉住了改动。 整体来看：这是一个优秀的小型修复的样子。问题在 #9430 中真实且可量化——两个 teammate 在 代码审查中的两条备注都属于外观层面——三处指引文案中的一处略有遗漏，以及路由谓词按该文件的既有惯例现在出现在四处。为一笔 36 行的修复扣住这两点不值得；如有人在意，可以作为后续改进。 一条如实记录的保留意见：套件中 TeamManager 是 mock 的，因此"真实启动在消耗 token 前拒绝"的端到端路径，依赖的是单元级拦截位于 先前的模板关卡（Stage 1a）保留为记录，但作者是仓库维护者且有意识地重新触发了 triage，流程细节不阻塞 re-run。LGTM，批准。✅ — Qwen Code · qwen3.8-max Reviewed at |
qwen-code-ci-bot
approved these changes
Aug 19, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
Collaborator
Author
|
@qwen-code /verify |
Collaborator
|
Sandboxed verification: The verification job did not complete (checkout, runner, or setup error) and produced no report. See the workflow run for details. 中文 — 判定：
|
yiliang114
changed the title
doudouOUC
approved these changes
Aug 19, 2026
doudouOUC
left a comment
doudouOUC
left a comment
Collaborator
There was a problem hiding this comment.
Review: APPROVE ✅
Independent verification at head 4712fad.
The gate logic is correct and consistent
- The new
validateToolParamsgate uses the exact routing predicate of the siblingmodelandisolationgates —params.name && !isTeammate() && isTopLevelSession() && this.config.getTeamManager()— plusrun_in_background === false, so it fires only whennamewould actually route to an active team. - It mirrors the
execute()team-routing branch precisely: the newelse if (this.params.run_in_background === false)block sits alongside the existingmodel/isolationblocks under the same guard and returns abuildSpawnBlockedResult. Validation-time reject and execute-time defense-in-depth stay in lockstep. - Fall-through paths are correct: with no active team
getTeamManager()is falsy, so neither the gate nor the execute branch fires andnamefalls through to a regular agent whererun_in_background: falseremains a valid foreground request. Nested (!isTopLevelSession()) calls also fall through, matchingshouldRunInBackground = backgroundRequested && isTopLevelSession(). - CI green.
Non-blocking Suggestions (already on the PR; fine to defer)
- L829 prose: the team-guidance remedy ends "…use a regular agent instead" while the three sibling surfaces say "…with
run_in_background: false". Harmless, but worth aligning for model-facing consistency. - L1170 / L1172: acceptance tests for the two fall-through paths (unnamed
run_in_background:falsewhile a team is active; nestedname+false) would guard theparams.name &&andisTopLevelSession()conditions. Test-only → Suggestion. - L1173: extracting a
wouldSpawnAsNamedTeammate()helper to dedupe the now-four inlined predicates is a nice cleanup.
None block merge. LGTM.
Collaborator
|
Released in v0.21.15. |
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
3 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.
What changed?
A named Agent Team teammate accepted
run_in_background: falsebut silently ignored it: the named-team route runs before the regular foreground/background classification and always returns right after spawn. The reported run launched five named teammates through an active team — three withrun_in_background: true, two withfalse— and all five returnedTeammate "<name>" is now running concurrently.while the two "foreground" launches kept working and consuming model tokens.Named teammates are inherently concurrent (persistent team identity, messaging, automatic final-report delivery), so foreground/inline semantics cannot apply. This PR makes the incompatible combination hard to generate and impossible to spawn:
nameproperty, and therun_in_backgroundschema description now state that named teammates always run concurrently and report through team messaging, that callers should omitrun_in_backgroundfor them, that an explicitfalseis rejected, and that an inline blocking result requires omittingnameand using a regular agent withrun_in_background: false.validateToolParamsrejectsrun_in_background: falsewhennameroutes to an active team, before any spawn. The gate mirrors theexecute()team-routing branch exactly: without an active team,namefalls through to a regular agent, where the foreground request remains valid.execute()team-routing branch carries the same rejection as abuildSpawnBlockedResultblock, mirroring the existingmodel/isolationblocks, so a hallucinated or wildcard-list call cannot spawn a teammate the caller believes is running inline.Risk & Scope
This changes the tool contract from silently ignoring
run_in_background: falseon a named teammate to rejecting it. Any caller or model-generated invocation that passesname+run_in_background: falsewhile a team is active will now receive a validation rejection (or an execute-time block) instead of a concurrent teammate — intended hardening, but a behavior change. When no team is active,namefalls through to a regular agent and the foreground request remains valid, so regular-agent workflows are unaffected. The concurrent teammate lifecycle itself is unchanged;run_in_background: true(or omitting it) with a teammate stays accepted.Fixes #9430
Verification
vitest run src/tools/agent/agent.test.ts— 262/262 passed, including four new cases:name+run_in_background: falsewith an active team;name+run_in_background: true;name+run_in_background: falsewhen no team is active (regular-agent fall-through);nameproperty and therun_in_backgrounddescription.tsc --noEmitclean forpackages/core;prettier --checkandeslintclean on both changed files.