feat(cli): add /fork background-agent command

[qqqys]

Summary

Adds a /fork <directive> slash command that spawns a background agent inheriting the full conversation (system prompt, history, tools, model, prompt-cache parity) and works the directive without blocking the main conversation. The fork reports back through the existing background-tasks panel and a terminal task-notification.

This realizes the /fork ⇄ /branch split: /fork = background agent, /branch = copy-to-new-session.

Implements QwenLM#4757.

What's included

Commit 1 — feat(cli): add /fork background-agent command

• New forkCommand.ts: routes through the Agent tool's background path (omitting subagent_type selects the implicit FORK_AGENT), reusing BackgroundTaskRegistry, live-activity tracking, JSONL transcript, stop, and the completion task-notification. Verified behaviorally identical to a model-launched fork.
• Guards: empty directive, missing config/model, mid-stream / in-flight, no conversation history yet, and a non-throwing failed launch (e.g. concurrency cap) is surfaced as an error instead of a false success.
• /branch drops its altNames: ['fork'] so /fork is unambiguous; /branch keeps the copy-to-new-session behaviour.
• Registered unconditionally as a built-in command (no feature flag) — directly usable.

Commit 2 — fix(cli): sanitize ANSI/control sequences in background-tasks dialog

• The background-tasks dialog rendered entry labels/titles/activity/prompt without sanitization, while the sibling LiveAgentPanel and /tasks already strip control codes. Since /fork directives flow into an entry's description/prompt, a raw escape sequence could reach the terminal when the dialog opens. Wrapped those renders in escapeAnsiCtrlCodes. Benefits all background agents, not just forks.

Testing

• forkCommand.test.ts (11) — guards, full-tool launch, inherited history, failed-launch detection.
• BuiltinCommandLoader.test.ts — /fork is always registered.
• BackgroundTasksDialog.test.tsx — ANSI/control-sequence injection guard, plus existing render suite.
• Manually verified via npm run dev: /fork launches a background agent that inherits the conversation, appears in the inline tracker (main / ○ fork: …), runs non-blocking, and reports its result back into the session.

Notes / follow-ups

• Not in this PR: pressing Enter to switch the main viewport into a fork's live transcript, and @mention-ing an agent. These are tracked as follow-up UX work.

[github-actions]

📋 Review Summary

This PR introduces a /fork <directive> slash command that spawns a background agent inheriting the full conversation context, and adds ANSI/control-sequence sanitization to the background-tasks dialog. The implementation is well-structured, reuses existing background-agent machinery, and includes solid test coverage. However, there is a TypeScript compilation error that must be fixed before merging.

🔍 General Feedback

• Good: The /fork ⇄ /branch split is clean and well-motivated — removing the altNames: ['fork'] alias from /branch eliminates ambiguity.
• Good: The fork command reuses the existing BackgroundTaskRegistry, live-activity tracking, JSONL transcript, and task-notification infrastructure rather than introducing new paths.
• Good: Guard coverage is thorough — empty directive, missing config/model, mid-stream/in-flight, no history, agent tool unavailable, throw-on-launch, and failed-without-throwing are all handled.
• Good: The escapeAnsiCtrlCodes fix in BackgroundTasksDialog is a valuable security/safety improvement that benefits all background agents, not just forks.
• Good: Test coverage is strong with 11 fork-specific tests covering guards, full-tool launch, inherited history, failed-launch detection, and the ANSI sanitization guard.

🎯 Specific Feedback

🔴 Critical

• File: forkCommand.ts:115 — TypeScript compilation error: agentTool.build(params).execute() is called with no arguments, but the ToolInvocation.execute() interface requires signal: AbortSignal as its first parameter (as shown in the .d.ts declaration: execute(signal: AbortSignal, ...)). This causes tsc --noEmit to fail with:

  error TS2554: Expected 1-3 arguments, but got 0.
  

  Suggested fix: Pass an AbortSignal to execute(). Options:

  1. Use context.signal if available on the command context.
  2. Create a new AbortController and pass controller.signal (the fork is detached, so it doesn't need to be tied to the parent's lifecycle).
  3. Alternatively, use agentTool.buildAndExecute(params, signal) if that convenience method is available — it wraps build().execute() internally.

  The test mocks hide this issue because mockBuild.mockReturnValue({ execute: mockExecute }) returns a mock execute that accepts zero arguments. Add a type-aware mock or run tsc --noEmit in CI to catch this.

🟡 High

• File: forkCommand.ts:79-80 — The history check calls config.getGeminiClient().getHistory(true) synchronously. If getGeminiClient() can throw when the client hasn't been initialized yet (e.g., before first API connection), the try/catch handles it, but the guard ordering means getModel() is checked first. Consider whether getGeminiClient() could return undefined/null rather than throwing, which would cause a runtime error on .getHistory(true).

🟢 Medium

• File: forkCommand.ts:130-137 — The llmContent fallback logic uses typeof result.llmContent === 'string' && result.llmContent.trim() to extract the failure reason. However, result is typed as ToolResult which may have llmContent as string | undefined. The typeof check is correct but the cast-free access to result.llmContent relies on the type being loose enough. Consider adding a type guard or narrowing for clarity.

• File: forkCommand.test.ts:29-32 — The mock for @qwen-code/qwen-code-core only provides ToolNames: { AGENT: 'agent' }. This means any other imports from core (like AgentParams type) that the test file might transitively depend on via forkCommand.ts are not mocked. This works because the test mocks the i18n module separately and vitest handles the module graph, but it's fragile — if forkCommand.ts imports a runtime value from core beyond ToolNames, the mock would need updating.

🔵 Low

• File: forkCommand.ts:148 — The success message is quite long: 'Forked into a background agent. It inherits this conversation and runs without blocking — track it in the background tasks panel; it reports back when done.' Consider shortening for TUI readability. The user already sees the background-tasks pill inline, so the full explanation may be unnecessary.

• File: forkCommand.ts:21 — supportedModes: ['interactive'] as const — good explicit declaration, but verify this is consistent with how other commands declare this property. Some commands omit it entirely.

• File: branchCommand.ts (PR version) — The description still says 'Fork the current conversation into a new session' which now uses the word "fork" in the description of /branch. Consider changing to 'Copy the current conversation into a new session' to avoid confusion with the new /fork command.

✅ Highlights

• The ANSI sanitization in BackgroundTasksDialog is a great proactive fix — preventing terminal-injection via user-controlled /fork directives is the right call, and it hardens all background-agent rendering paths.
• The test for deriveForkDescription truncation (200-char directive → ≤60 char label) is well-chosen and verifies the label stays human-readable.
• The failed-launch detection (both thrown exceptions and resolved-with-failed-status) shows thorough understanding of the Agent tool's error semantics.

[qqqys]

Superseded by the upstream PR QwenLM#4780 (same change, rebased onto upstream main).