Spawn Refactor & MCP Fixes

[khaliqgant]

---

[devin-ai-integration]

Devin Review found 2 potential issues.

View 5 additional findings in Devin Review.

[devin-ai-integration]

🟡 Memory leak: recentlyDisconnectedUsers cleanup only runs during agent spawning

The recentlyDisconnectedUsers map tracks disconnected user connections for 5 minutes to ensure messages to them are persisted. However, cleanup of stale entries only occurs in cleanupStaleSpawning(), which is exclusively called from markSpawning() (packages/daemon/src/router.ts:216).

Root Cause

The cleanup logic at packages/daemon/src/router.ts:254-260 runs inside cleanupStaleSpawning(), but this method is only invoked when an agent is being spawned. If no agents are spawned for an extended period, stale entries accumulate indefinitely.

// router.ts:210-217
markSpawning(agentName: string): void {
  this.spawningAgents.set(agentName, Date.now());
  routerLog.info(`Agent marked as spawning: ${agentName}`, {
    currentSpawning: Array.from(this.spawningAgents.keys()),
  });
  // Clean up stale spawning entries
  this.cleanupStaleSpawning();  // ← Only called here
}

// router.ts:254-260
private cleanupStaleSpawning(): void {
  // ... spawning cleanup ...
  // Also clean up stale recently-disconnected user entries
  for (const [name, timestamp] of this.recentlyDisconnectedUsers) {
    if (now - timestamp > Router.RECENT_USER_TTL_MS) {
      this.recentlyDisconnectedUsers.delete(name);
      routerLog.debug(`Cleaned up stale recently-disconnected user: ${name}`);
    }
  }
}

Impact: In long-running daemon instances with infrequent agent spawning, the recentlyDisconnectedUsers map grows unbounded with stale entries. Each CLI command that connects as __cli_sender__ and disconnects adds an entry that won't be cleaned up until the next spawn operation.

Example scenario: A daemon running for hours with agents only sending/receiving messages (no spawning) will accumulate every disconnected user entry from CLI commands.

Prompt for agents

Add a periodic cleanup mechanism for recentlyDisconnectedUsers that runs independently of spawning operations. Options:

1. Create a separate periodic timer in the Router constructor that runs cleanupStaleSpawning() every 5 minutes
2. Add cleanup logic to other frequently-called methods like register() or unregister()
3. Extract the recentlyDisconnectedUsers cleanup into a separate method and call it from both cleanupStaleSpawning() and from a periodic interval

Recommended approach is option 3 - create a cleanupStaleRecentUsers() method and call it both from cleanupStaleSpawning() and set up a periodic interval (every 5 minutes) in the Router constructor that calls both cleanup methods. Remember to clear the interval in a destructor/cleanup method if one exists.

---

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

[devin-ai-integration]

🟡 Missing error handling when no release mechanism available in executeReleaseWithFallbacks

The executeReleaseWithFallbacks() method silently returns without error when no release mechanism is available (daemon not connected, no dashboard, no callback). This is inconsistent with the equivalent spawn method which throws an error.

Root Cause

At packages/wrapper/src/relay-pty-orchestrator.ts:1484-1488, if all release mechanisms fail or are unavailable, the function silently returns:

// 3. Final fallback: onRelease callback
if (this.config.onRelease) {
  await this.config.onRelease(name);
  return;
}
// ← Function ends here with implicit undefined return

Compare this to executeSpawnWithFallbacks() at line 1432 which explicitly throws:

if (this.config.onSpawn) {
  this.log(`Spawning ${name} via onSpawn callback`);
  await this.config.onSpawn(name, cli, task);
  return;
}

throw new Error(`No spawn mechanism available (client=${this.client.state}, dashboardPort=${this.config.dashboardPort}, onSpawn=${!!this.config.onSpawn})`);

Impact: When an agent attempts to release another agent but:

• Daemon is not connected (client.state !== 'READY')
• Dashboard API is not available (config.dashboardPort is undefined)
• No onRelease callback is configured

The release silently fails with no indication to the calling agent. The calling code at line 1448 catches and logs the error, but since no error is thrown, it appears the release succeeded when it actually did nothing.

Actual behavior: Release command is silently ignored

Expected behavior: Throw an error indicating no release mechanism is available, matching the spawn behavior

Suggested change

	// 3. Final fallback: onRelease callback
	if (this.config.onRelease) {
	await this.config.onRelease(name);
	return;
	}
	// 3. Final fallback: onRelease callback
	if (this.config.onRelease) {
	await this.config.onRelease(name);
	return;
	}
	throw new Error(`No release mechanism available (client=${this.client.state}, dashboardPort=${this.config.dashboardPort}, onRelease=${!!this.config.onRelease})`);
	}

---

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