feat: daemon-based spawning for spawn CLI command#361
Merged
Conversation
The `spawn` command now communicates directly with the daemon via socket protocol, removing the requirement for the dashboard to be running. Falls back to HTTP API (dashboard) if daemon socket is unavailable. This simplifies agent orchestration - just `agent-relay up` is sufficient for spawn/release operations. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
When socket is in /tmp, use /tmp/agent-relay-state/ subdirectory for teamDir. Fixes atomic write failures on macOS where temp file cleanup can remove files between write and rename operations. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Shadow options (shadowMode, shadowAgent, shadowTriggers) were silently dropped when spawning via the daemon socket path. The HTTP API fallback passed all fields via JSON.stringify, but the SDK path used explicit field listing that missed these three fields. Thread shadowMode, shadowAgent, and shadowTriggers through: - Protocol SpawnPayload type - SDK client.spawn() options and envelope payload - Daemon SpawnManager.handleSpawn() pass-through - CLI client.spawn() call Add SDK test verifying shadow options appear in sent envelope. Add sdk-daemon-parity Claude rule to prevent future field omissions. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Move daemonSpawnSucceeded and daemonReleaseSucceeded flags to before the disconnect() call. This ensures that if disconnect() throws an error, successful spawns/releases are still correctly reported rather than being treated as failures. Addresses Devin review comments on PR #361. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Comment on lines
+2447
to
2456
| } catch (daemonErr: any) { | ||
| // If daemon connection failed, try HTTP API as fallback | ||
| if (daemonErr.message?.includes('ENOENT') || daemonErr.message?.includes('ECONNREFUSED') || daemonErr.code === 'ENOENT') { | ||
| // Socket doesn't exist or daemon not running - try HTTP API | ||
| } else if (!daemonSpawnSucceeded) { | ||
| // Other error during spawn - report it | ||
| console.error(`Failed to spawn ${name}: ${daemonErr.message}`); | ||
| process.exit(1); | ||
| } | ||
| } |
Contributor
There was a problem hiding this comment.
🔴 Duplicate spawn/release attempts after disconnect error
When the daemon spawn/release operation succeeds but client.disconnect() throws an error, the code falls through to the HTTP API fallback and attempts the operation again.
Click to expand
How the bug is triggered
await client.spawn()succeeds atsrc/cli/index.ts:2418-2430daemonSpawnSucceeded = trueis set at line 2433await client.disconnect()throws an error at line 2434- The catch block is entered at line 2447
- The error message doesn't include 'ENOENT' or 'ECONNREFUSED' (it's a disconnect error)
!daemonSpawnSucceededisfalse, so the exit at line 2454 is skipped- Code falls through to HTTP API fallback at line 2458
- HTTP API tries to spawn the same agent again!
Actual vs Expected
Actual: If disconnect fails after a successful spawn, the code will attempt to spawn the agent again via HTTP API, potentially causing duplicate agents or errors.
Expected: If the spawn operation succeeded, the command should exit successfully regardless of disconnect errors.
Impact
This can cause:
- Duplicate spawn attempts for the same agent name
- Confusing error messages if the second spawn fails because the agent already exists
- Resource waste from unnecessary HTTP API calls
The same bug exists in the release command at lines 2518-2538.
Recommendation: Add process.exit(0) after the catch block when daemonSpawnSucceeded is true, or restructure the error handling to exit early when the operation succeeded. For example:
} catch (daemonErr: any) {
if (daemonSpawnSucceeded) {
// Spawn succeeded, disconnect error is non-fatal
process.exit(0);
}
// ... rest of error handling
}
Was this helpful? React with 👍 or 👎 to provide feedback.
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
1 participant
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.
The
spawncommand now communicates directly with the daemon via socket protocol, removing the requirement for the dashboard to be running. Falls back to HTTP API (dashboard) if daemon socket is unavailable.This simplifies agent orchestration - just
agent-relay upis sufficient for spawn/release operations.