Skip to content

buildQueueDirective

buildQueueDirective(args): string

Defined in: src/service.ts:528

Build the build-queue directive injected at spawn when the repo has buildQueueEnabled.

The build queue is a per-session, ordered, self-revising plan: the agent authors it via a local REST API right after reading the task, a human (or autopilot) approves it, then the agent executes it step-by-step IN THIS SAME SESSION so it retains full context throughout.

Why bake the actual endpoint + session id at spawn time (rather than leaving the agent to discover them)? Two reasons:

  1. Reliability: the agent doesn’t have to guess the server address or its own session id under an unattended run — a misread would silently produce an unreachable URL.
  2. Curation gate: the autopilot/attended split is a policy decision that should be stated up front, not inferred mid-run. The agent knows BEFORE starting whether it must wait for human approval or may immediately execute after authoring.

Token/auth: when config.token is set the server requires Authorization: Bearer <token>; when null it’s open to loopback callers — the curl lines must match exactly.

SECURITY NOTE: baking the bearer token into the spawn prompt means it is persisted into the agent’s Claude Code transcript jsonl on disk (~/.claude/projects/.../<session>.jsonl). This is an accepted exposure, not an oversight: the token is Shepherd’s own loopback control-plane secret, the transcript lives under the same user account on the same host, and the agent is already spawned with --dangerously-skip-permissions (it can read that token from the running server’s env or config anyway). The exposure is also opt-in — most deployments leave config.token null, so nothing is written. It is NOT a credential that reaches any third party.

Agent-facing prompt text (not operator UI), so fixed English — same precedent as AUTOPILOT_DIRECTIVE, BRANCH_RENAME_NOTICE, and the other spawn-constant notices.

boolean

string

string

string | null

string