Skip to content

bakers oven ​

bakers oven is the node agent: it registers this machine's conductor for a project checkout, claims tickets and runs agents on them, using the checkout's existing configuration.

This page is the command reference. What a cycle does and how to run several conductors is in Conductors; the config file is in Conductor configuration.

Synopsis ​

bakers [--conductor <name>] oven [--log-level <level>] [--log-sink <sink>] <subcommand>

Every subcommand except ls works on the conductor of the checkout you stand in, found by walking up from the working directory to a .bakers/ directory that holds a conductor config. start, once and clean need a signed-in connection and stop with a pointer to bakers dropsh auth login when there is none.

Global flags ​

FlagWhereEffect
--conductor <name>before conductorSelect a conductor config by file stem: conductor is conductor.config.js, anything else <name>.conductor.config.js. Environment: $BB_CONDUCTOR; the flag wins.
--log-level <level>after ovendebug, info (default), warn or error. Environment: BB_LOG_LEVEL. debug shows per-poll ticks, claims and idle cycles.
--log-sink <sink>after ovenstdout, file or both. Default both on a terminal, file otherwise. file and both write .bakers/log.txt in the checkout. Environment: BB_CONDUCTOR_LOG.

With no --conductor, the default is conductor.config.js; if that file is absent and exactly one config exists it is used, and with several you must choose or the command lists the stems and stops.

sh
bakers oven --log-level debug start --foreground
bakers oven --log-level debug once
BB_LOG_LEVEL=debug bakers oven once

Subcommands ​

SubcommandOptionsWhat it does
start--foreground, --no-update-check, --forceStart the conductor loop
oncenoneRun one conductor cycle, then exit
checknoneCheck that every enabled agent can start its sandbox
statusnoneOne line for this checkout's conductor
lsnoneOne line per conductor the control plane holds for you
stop--nowStop the conductor: graceful by default, hard kill with --now
cleannoneTear down herdr worktrees of finished tickets that were never cleaned up

start ​

By default start launches the loop in a herdr pane (handle bakers-conductor:<id>) and waits until the control plane shows a fresh heartbeat from the new process. It ends with exactly one of three outcomes: started (naming the pid and host), already running (the live pid and the age of its heartbeat) or failed (the reason, with a non-zero exit status). On a host without herdr, run bakers oven start --foreground under a service manager such as systemd or Docker.

  • --foreground runs the loop in this process instead. It refuses to start while a verified live conductor already serves the checkout. Every foreground start, and every CI or non-TTY start, prints an update notice only and never prompts.
  • --no-update-check skips the lookup, cache, prompt and notice; the version banner still prints.
  • --force turns "already running" into a restart: a verified SIGTERM, a grace period, then SIGKILL, then the normal start. It fails rather than starting a second conductor when the running one cannot be verified or stopped.

An interactive plain start (TTY stdin and stdout, empty CI, no --foreground) offers to install a newer release and migrate configuration before any lifecycle work. The procedure, decline window, rerun and failure behaviour are in Update bakers.build.

A start on a machine where an enabled agent cannot start its sandbox prints warning: sandbox unavailable: <agent>: <cause> — <fix> and still starts; the loop then claims nothing until the cause is fixed (see check).

check ​

check prints one line per enabled agent: <agent>: sandbox ok, or sandbox unavailable: <agent>: <cause> — <fix> (see https://bakers.build/docs/advanced/run-security#sandbox-prerequisites). It exits 1 when one agent cannot start its sandbox and needs no sign-in. While that is so, every cycle logs claims withheld: sandbox unavailable: … and claims nothing. Prerequisites per platform: Sandbox prerequisites.

once and clean ​

once registers the conductor, runs a single claim-and-run cycle and exits, which is the tool for diagnosing a conductor that seems idle. clean recovers worktrees that a live cycle missed, for example when the conductor was down at done, restarted, or the ticket was reassigned.

stop ​

stop sends SIGTERM to the pid recorded on the control plane, after checking that the pid belongs to a conductor process of this host; the exiting conductor writes its own offline status. --now sends SIGKILL instead; a killed process writes nothing, so the status follows when its lease expires. stop cannot stop a conductor that runs on another machine. If another record names the same checkout it is reported and left untouched.

status and ls ​

Both print tab-separated columns, status only for this checkout's conductor and ls for every conductor you own, on any machine:

<conductor_id>	<liveness>	<project>	<label>	<workspace_root>

Liveness is derived, and uses the same three words as the cockpit and the control plane: online (heartbeating within its lease), stale (registered as online, but the heartbeat is older than 600 seconds or the lease has lapsed, which is what a crash looks like) and offline (shut down cleanly). For a conductor on this host whose recorded process no longer exists, the listing reports offline. With no conductors, the output is no conductors on the control plane. The bakers oven ls --help text says "on this machine"; the listing is not limited to it.

Environment ​

VariableEffect
BB_CONDUCTORDefault for --conductor
BB_CONDUCTOR_CONFIGExplicit conductor config path; wins over discovery
BB_LOG_LEVELDefault for --log-level
BB_CONDUCTOR_LOGDefault for --log-sink

Scoped setup is done by bakers config and bakers init; conductor init no longer exists.