Daemon Lifecycle

Switchboard has a local daemon lifecycle foundation. The daemon currently proves local process, PID/state, socket management, heartbeat, and daemon-side tool discovery. switchboard mcp can expose daemon-backed tool listings to MCP clients and route tool calls through the daemon, while switchboard serve remains the daemonless debug and CI fallback.

Commands

switchboard daemon status
switchboard daemon start
switchboard daemon ping
switchboard daemon tools
switchboard daemon stop
switchboard mcp

For automation:

switchboard daemon status --json
switchboard daemon start --json
switchboard daemon ping --json
switchboard daemon tools --json
switchboard daemon stop --json
switchboard mcp --runtime-dir <path>
switchboard mcp --mandate <id>

Runtime Files

Switchboard resolves daemon runtime files from:

$SWITCHBOARD_RUNTIME_DIR
$XDG_RUNTIME_DIR/switchboard
/tmp/switchboard-<uid>

The runtime directory contains:

daemon.sock
daemon.json

daemon.json stores the PID, socket path, and start time with private file permissions. switchboard daemon stop removes stale or invalid state.

Daemon Tool Discovery

switchboard daemon tools asks the running daemon to load the active Switchboard config, start configured stdio upstream profiles, discover their tools through the shared MCP router, return namespaced tool metadata, and close the temporary upstream sessions.

The daemon inherits the repo config root from switchboard --cwd <repo> daemon start. This keeps daemon discovery aligned with switchboard --cwd <repo> serve and switchboard --cwd <repo> test <profile>.

Daemon-Backed MCP Adapter

switchboard mcp serves MCP over stdio, auto-starts the local daemon when needed, and asks the daemon for namespaced tool metadata and tool-call routing. Routed calls are audited by the daemon using the same local JSONL audit log format as switchboard serve.

For manual testing, use:

switchboard --cwd <repo> mcp

To run under an active task-scoped mandate, use:

switchboard --cwd <repo> mcp --mandate fix-ci

To keep approval-gated tool calls open while a local decision arrives, add a bounded wait:

switchboard --cwd <repo> mcp --mandate fix-ci --approval-wait 30s

The adapter validates that the mandate is active for the repo, asks the daemon to mount only the mandate's profiles, enforces the mandate's allow, deny, and approval-required namespaced tool patterns before routing calls, and attaches the mandate id to routed tool-call audit entries. Approval-required tools remain visible in tools/list with _meta.switchboard.approvalRequired, but execution still creates local approval requests that can be listed with switchboard approvals and decided with switchboard approve <id> or switchboard deny <id>. Approval gates never expand the allow list: a tool outside allowedTools remains hidden and blocked even if it matches an approval gate. If the connected MCP client advertises form elicitation support, the daemon-backed MCP front door can ask for an in-client approve/deny decision, persist the decision through that same local approval store, and retry approved tool calls. With --approval-wait, the daemon polls for a local CLI decision for up to the requested duration. If the MCP client disconnects during that wait, the daemon marks the approval request stale so it cannot be approved after the originating call is gone. This is basic local approval handling, not provider-specific policy or secret access yet.

Use switchboard mcp --no-auto-start to fail fast unless a daemon is already running.

Current Limits