Thanks for the PR, @qqqys — and for the follow-up commit fixing the resume path.

Template headings diverge from the PR template ("## What" / "## Test" instead of "## What this PR does" / "## Why it's needed" / "## Reviewer Test Plan"), but all substantive content is present. Not blocking — just a heads-up for next time.

On direction: this is squarely in scope. The fork subagent runs fire-and-forget in the background with no inline UI — shipping it without a turn cap and with auto-deny on permission prompts was a clear robustness gap. Both fixes address real failure modes (unbounded token burn and silently denied tool calls), and closing #5734 confirms the user impact.

On approach: the scope is minimal — a constant, a field change, and two call-site updates. Nothing to cut. The BUBBLE_APPROVAL_MODE reuse is exactly right; it was designed for this case.

Moving on to code review. 🔍

— Qwen Code · qwen3.7-max

Code Review

Independent proposal: Before reading the diff, I'd solve this with (1) a FORK_DEFAULT_MAX_TURNS constant exported from fork-subagent.ts and passed as RunConfig at both AgentHeadless.create call sites (fresh fork in agent.ts, resumed fork in background-agent-resume.ts), and (2) changing FORK_AGENT.approvalMode from 'default' to BUBBLE_APPROVAL_MODE so that permission prompts surface via the parent's Background-tasks UI.

Diff comparison: The PR matches this approach exactly. Both call sites are covered (the second commit a65273a0 added the resume path that the initial PR missed — good catch by the previous reviewer). The constant is co-located with FORK_AGENT in fork-subagent.ts, the unused RunConfig type import is cleaned up in both consumer files, and the new test cases assert on the exact positional arguments.

Findings:

• No correctness bugs. The { max_turns: FORK_DEFAULT_MAX_TURNS } RunConfig is passed as the 5th positional arg to AgentHeadless.create(), which maps to runConfig.max_turns in agent-core.ts → maxTurnsPerMessage in InProcessBackend.ts. The turn loop in agent-core.ts checks this and terminates with MAX_TURNS when exceeded.
• The BUBBLE_APPROVAL_MODE change is safe. isForkSubagentEnabled gates fork availability to interactive sessions only (config.isInteractive()), so bubble will always have a parent UI to surface to. Non-interactive paths never reach this code.
• One minor note: the validation.ts module caps user-defined max_turns at 100, while FORK_DEFAULT_MAX_TURNS is 200. Not a bug — the validator runs on user-provided subagent configs, and this programmatic path bypasses it entirely. Just worth knowing in case the validator threshold changes later.

No blockers found.

Testing

These changes are purely internal to fork subagent dispatch — no TUI-visible behavior to exercise in tmux. Verification is through the unit test suite:

• agent.test.ts — new case asserts createArgs[4] === { max_turns: FORK_DEFAULT_MAX_TURNS } and FORK_AGENT.approvalMode === BUBBLE_APPROVAL_MODE
• background-agent-resume.test.ts — asserts the resume path also carries max_turns: FORK_DEFAULT_MAX_TURNS and adds the missing isInteractive: () => false mock

The PR author reports packages/core tests green (159 passing) and packages/cli typecheck green. CI should confirm.

— Qwen Code · qwen3.7-max

This PR does exactly what it says — two focused robustness fixes for the fork subagent, each addressing a real failure mode. The scope is minimal (a constant, a field change, two call-site updates, two test assertions), and there's no drive-by refactoring or scope creep.

My independent proposal matched the PR's approach exactly, which is a good sign — the solution is the obvious one. The second commit fixing the resume path shows the author is responsive to review feedback. wenshao has already approved, and I agree with that assessment.

The code is straightforward, the comments explain why (not what), and the tests assert on the exact contract that matters. If I had to maintain this in six months, I'd thank the author.

Approving. ✅

— Qwen Code · qwen3.7-max

CI failure root cause — FORK_AGENT approval-mode flip trips a missing mock method (test-only)

The 3 red Test jobs (ubuntu/macos/windows) all fail at the same place — 3 tests in one file, packages/core/src/agents/background-agent-resume.test.ts:

× resumes fork agents from transcript bootstrap instead of current parent config → expected undefined to be defined
× keeps legacy fork tasks paused when transcript bootstrap is missing      → resumeBlockedReason is undefined
× keeps fork tasks paused when bootstrap capabilities are missing          → resumeBlockedReason is undefined
 Test Files  1 failed | 438 passed | 1 skipped
       Tests  3 failed | 12952 passed | 8 skipped

(Lint, build, and the No-AK smoke test all pass — this is a unit-test failure, not a compile error.)

Root cause. This PR flips FORK_AGENT.approvalMode from 'default' to BUBBLE_APPROVAL_MODE (packages/core/src/tools/agent/fork-subagent.ts:39). The fork resume path has a pre-existing bubble gate at packages/core/src/agents/background-agent-resume.ts:703-705:

const shouldBubble = Boolean(
  target.subagentConfig?.approvalMode === BUBBLE_APPROVAL_MODE &&
    this.config.isInteractive(),   // <- only reached now that the LHS is true
);

• Before: FORK_AGENT.approvalMode === 'default', so ... === BUBBLE_APPROVAL_MODE is false and the && short-circuits — this.config.isInteractive() is never called on the fork path.
• After: the LHS is true, so the && proceeds to call this.config.isInteractive().

The fork-resume tests build a hand-rolled mock Config (createService(), background-agent-resume.test.ts:82-108, cast as unknown as Config) that does not define isInteractive. So the call throws:

TypeError: this.config.isInteractive is not a function
    at resumeBackgroundAgentInternal (background-agent-resume.ts:705)

That throw is swallowed by the resume body's outer catch, which re-pauses the entry with a generic error (not a resumeBlockedReason) and returns undefined. That single throw explains all 3 assertions at once:

• test 1 expects resumed to be defined → gets undefined (the caught throw);
• tests 2 & 3 throw at line 705 before reaching the gates that set resumeBlockedReason → that field stays undefined.

This is a test-mock gap, not a product bug. The real Config implements isInteractive() (packages/core/src/config/config.ts:4451), so the resume path is fine in production — the change to bubble fork permission prompts is sound. Only the test's fake config is missing the method.

Fix (one line). Add isInteractive to the shared mock in createService():

       isTrustedFolder: () => true,
+      isInteractive: () => false,
       getProjectRoot: () => tempDir,

Verification. I reproduced and bisected this locally:

1. Merge-base (pure main, no PR): the 4 fork-resume tests pass.
2. PR head: the same 3 fail, identical to CI.
3. Reverting only the approvalMode line (keeping the turn-cap + agent.ts changes) makes them pass → approvalMode is the sole trigger.
4. Instrumented the catch → TypeError: this.config.isInteractive is not a function at background-agent-resume.ts:705.
5. Adding isInteractive: () => false to the mock → all 28 tests in the file pass (Tests 28 passed).

× resumes fork agents from transcript bootstrap instead of current parent config → expected undefined to be defined
× keeps legacy fork tasks paused when transcript bootstrap is missing      → resumeBlockedReason 为 undefined
× keeps fork tasks paused when bootstrap capabilities are missing          → resumeBlockedReason 为 undefined
 Test Files  1 failed | 438 passed | 1 skipped
       Tests  3 failed | 12952 passed | 8 skipped

const shouldBubble = Boolean(
  target.subagentConfig?.approvalMode === BUBBLE_APPROVAL_MODE &&
    this.config.isInteractive(),   // <- 现在 LHS 为 true 才会走到这里
);

TypeError: this.config.isInteractive is not a function
    at resumeBackgroundAgentInternal (background-agent-resume.ts:705)

       isTrustedFolder: () => true,
+      isInteractive: () => false,
       getProjectRoot: () => tempDir,

@qwen-code /triage

✅ E2E verification — fork turn cap & permission bubbling

Built the CLI from this PR's HEAD (a65273a0) and drove the real interactive TUI via tmux against a deterministic mock OpenAI server (so a detached fork reliably emits tool calls). Each fix was A/B-tested by swapping only the built dist between this PR's behavior and the pre-PR behavior, holding the other change constant — so every difference below is attributable to exactly one line of the diff.

Fix 2 — bubble fork permission prompts (FORK_AGENT.approvalMode)

Fork directed to call a permission-gated tool (write_file); max_turns: 200 held constant in both arms:

The bubbled prompt, exactly as it appears in the parent session (↓ opens the background-tasks panel → Enter for detail):

fork › create the marker file please
1 tool call

Progress
> WriteFile(Writing to fork_marker.txt)

 Background agent needs approval
 1 FORK_E2E_MARKER
 Apply this change?
 › 1. Yes, allow once
   2. No

Footer pill in default view: 1 local agent ⚠ needs approval. Selecting Yes lets the fork finish the write — confirming permission prompts now reach the user instead of being silently swallowed.

Fix 1 — cap fork turns (max_turns: FORK_DEFAULT_MAX_TURNS = 200)

Non-converging fork (model keeps requesting an auto-approved tool); approvalMode: 'bubble' held constant in both arms:

Deterministic layer

• npm run build ✅ (0 errors)
• fork unit tests ✅ — agent.test.ts (111) + background-agent-resume.test.ts (28), 139 passing, including the new max_turns: 200 and approvalMode === BUBBLE_APPROVAL_MODE assertions.

Scope notes

• The launch path (agent.ts) and approvalMode (fork-subagent.ts) were exercised end-to-end. The resume path cap (background-agent-resume.ts) is the identical one-line change and is covered by the unit suite, not separately driven in the live harness.
• A mock model was used only to make the fork deterministically emit tool calls; all code under test is the real built artifact, unmodified except for the A/B dist swaps described above.

Verdict: both fixes behave exactly as described — the gated-tool prompt now bubbles to the user, and a runaway fork is bounded at 200 turns. LGTM for merge. ✅

fork › create the marker file please
1 tool call

Progress
> WriteFile(Writing to fork_marker.txt)

 Background agent needs approval
 1 FORK_E2E_MARKER
 Apply this change?
 › 1. Yes, allow once
   2. No