How agent credentials work

Earlier versions of the Meshly Build daemon required you to copy each agent's API key from the dashboard and paste it into a config file. Build Station does that automatically.

How it works

1. You sign in to Build Station

OAuth flow. The result: an access token for your user identity in your keychain.

2. Build Station enumerates your agents

On each resync, the backend tells Build Station which agents you have access to.

3. For each agent, fetch its API key

Build Station calls a privileged endpoint that returns the agent's bearer token. Your access token (the one for YOUR user identity) authorizes this call.

4. Store in keychain, one entry per agent

macOS Keychain or Windows Credential Manager. Each agent gets its own entry — never written to disk in plain text.

5. Use the key when spawning that agent's tasks

The bearer token goes into the agent's per-spawn MCP config, so the spawned Claude session authenticates as the right identity.

Per-spawn identity

Every Claude Code session Build Station spawns gets its own MCP config in a temp file with the assigned agent's bearer token. That config is passed to claude --mcp-config <path> --strict-mcp-config — the --strict-mcp-config flag makes Claude ignore the project's working-dir .mcp.json so there's no key confusion.

The upshot: if a project has two enabled agents (X and Y) and the dashboard dispatches one task to each, X's session authenticates as X server-side, Y's as Y. Activity log attribution on the dashboard correctly reflects which agent did what.

Note: Why per-spawn instead of just one config

The working-dir .mcp.json is shared across the whole project. It can only encode one agent's identity at a time. The per-spawn temp file lets every concurrent spawn carry its own identity without stepping on the shared file.

Key rotation

When a key is rotated on the backend (manually or automatically), it changes server-side. Build Station's local copy goes stale.

• On next resync the new key is fetched and overwrites the old one in your keychain.
• In-flight sessions keep using their existing key for the duration of the session. Sessions are short (one task), so the impact window is small.
• Failed authentication (which would happen if the key changed between resync and spawn) shows up in the agent's console as an MCP connection error. The task gets retried automatically; the second attempt uses the freshly-fetched key.

What you do NOT need to do

• Open the dashboard and copy a key.
• Paste a key into a config file.
• Worry about key expiration — rotation is handled automatically when the backend reports a new one.

What you DO need to do

Just be signed in. Your access token is the master credential — everything else flows from that.

Forgot to sign in to a fresh machine?

If you've never signed in on this Build Station, no keys exist locally yet. Sign in via the standard OAuth flow (Signing in). The first resync after sign-in fetches all your agent keys.

Switching accounts

If you sign out and back in as a different user (different identity on the same instance, or a different instance), Build Station wipes the old user's agent keys from the keychain during sign-out. The new user's keys are fetched on first resync after the new sign-in. No leakage between accounts.

Inspecting what's stored

You can see (but not extract) Build Station's keychain entries.

• macOS: Open Keychain Access → search for "meshly-station". You'll see one entry per agent plus the user-level access/refresh tokens.
• Windows: Credential Manager → Windows Credentials. Look for entries with the meshly-station: prefix.

Building Station never logs the actual key values, even at trace log level.