fix: MCP tools unavailable for agents spawned via agent_add

[khaliqgant]

Summary

• Claude: Removed --strict-mcp-config from --mcp-config injection. The flag blocked .mcp.json loading, preventing MCP tools from being discovered. --mcp-config is now additive — only passes relaycast config while Claude loads user MCP servers from .mcp.json independently.
• All CLIs (claude, codex, gemini, etc.): Added broker-side agent pre-registration to the WS AgentSpawnRequested handler. The AgentSpawnRequestedPayload struct doesn't include a token field, so relaycast_ws_spawn_token() always returned None. Without a pre-registered token, the MCP server failed to authenticate at startup. Now the broker calls register_agent_token() before spawning (matching the SDK spawn_agent path that already worked).

Root Cause

Two independent issues combined to break MCP for agents spawned via agent_add:

1. For Claude: --strict-mcp-config told Claude "only use this inline config, ignore .mcp.json". If the inline MCP server failed to start for any reason, no MCP tools were available at all.

2. For all CLIs: The WS spawn path (used by agent_add) never pre-registered agents with the Relaycast API. The SDK spawn_agent path called http.register_agent_token() before spawning, giving the MCP server a valid token. The WS path skipped this, expecting the WS event to carry a token — but AgentSpawnRequestedPayload has no token field.

Test plan

• All 220 lib + 8 e2e Rust tests pass (cargo test)
• New integration test agent-spawns-agent.test.ts exercises the exact agent_add flow
• Claude test: agent spawned via Relaycast API successfully uses MCP tools to send DM
• Codex test: agent spawned via Relaycast API successfully uses MCP tools (1 relay_inbound)
• Gemini test (requires gemini CLI on PATH)
• Existing mcp-injection tests still pass (SDK spawnPty path unaffected)

🤖 Generated with Claude Code

---

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 6 additional findings in Devin Review.

[devin-ai-integration]

🟡 Output filter regex cannot match chalk-colored [workflow HH:MM] lines due to interleaved ANSI escape codes

The installOutputFilter() function in both cli.ts:77 and listr-renderer.ts:18 uses the regex /\[workflow\s+\d{2}:\d{2}\]/ to suppress noisy [workflow HH:MM] timing lines while the listr2 renderer owns the terminal. However, runner.ts:994 now formats these lines using three separate chalk.dim.cyan() calls:

console.log(`${chalk.dim.cyan('[workflow')} ${chalk.dim.cyan(ts)}${chalk.dim.cyan(']')} ${msg}`);

Each chalk call wraps its text in ANSI open/close escape sequences (e.g., \x1b[2m\x1b[36m[workflow\x1b[39m\x1b[22m). The regex expects [workflow to be immediately followed by \s+ (whitespace), but the actual string has ANSI reset codes (\x1b[39m\x1b[22m) between [workflow and the space character. Since \x1b is not a whitespace character, the \s+ quantifier fails and the regex never matches. As a result, all workflow timing lines leak through the filter into the listr2 output, creating cluttered/broken progress display — directly undermining the PR's goal of polished CLI output.

Prompt for agents

Fix the output filter in both packages/sdk/src/workflows/cli.ts (line 77) and packages/sdk/src/workflows/listr-renderer.ts (line 18) to strip ANSI escape codes before testing the regex, OR change runner.ts line 994 to wrap the entire `[workflow HH:MM]` prefix in a single chalk call so the literal text remains contiguous.

Option A (preferred — fix runner.ts:994):
Change from:
  console.log(`${chalk.dim.cyan('[workflow')} ${chalk.dim.cyan(ts)}${chalk.dim.cyan(']')} ${msg}`);
To:
  console.log(`${chalk.dim.cyan(`[workflow ${ts}]`)} ${msg}`);

This keeps `[workflow 00:05]` as contiguous text inside a single chalk call, so the existing regex matches.

Option B (fix the filters in cli.ts:77 and listr-renderer.ts:18):
Strip ANSI codes from `str` before testing:
  const plain = str.replace(/\x1b\[[0-9;]*m/g, '');
  if (/\[broker\]/.test(plain) || /\[workflow\s+\d{2}:\d{2}\]/.test(plain)) return;

---

Was this helpful? React with 👍 or 👎 to provide feedback.