Everything bullpen persists is resolved from the process's home directory: Store::default_path() returns home_dir()/.bullpen/bullpen.db, and the credential store sits beside it at ~/.bullpen/auth.json. There is no way to point either somewhere else.
That is fine for a human at a terminal and fatal for anything that supervises bullpen.
Why now
Scoping a jig runtime adapter for bullpen surfaced this as a hard blocker. jig composes the complete subprocess environment for each agent phase — a role's env allowlist plus an ephemeral HOME — deliberately, so a phase cannot reach the operator's environment.
Run bullpen under that and every phase gets a brand new, empty store. Resume — the entire reason to wrap bullpen instead of a stateless CLI — silently stops working.
Worse, it fails late. The first send succeeds and mints a session id. The second send passes that id to run -r against a store that has never seen it. The error surfaces two phases into a run, nowhere near the cause.
What
Resolve the bullpen home from BULLPEN_HOME when set, falling back to $HOME/.bullpen when not.
Scope it to the whole directory, not just the database — auth.json has the same problem, and one concept is easier to reason about than two:
BULLPEN_HOME=/path → store at /path/bullpen.db, credentials at /path/auth.json- unset → today's behaviour exactly,
$HOME/.bullpen/…
Notes
- Env var rather than a flag, chosen for the supervising-process case: jig injects environment, and threading a
--store flag through every subcommand is more surface for the same result. A flag can come later if a human wants one; the env var is what unblocks the adapter.
- Purely additive. With
BULLPEN_HOME unset nothing changes, so no existing store moves and no migration is needed.
- Worth a test that asserts the fallback still lands on
$HOME/.bullpen, so a future refactor cannot quietly relocate everyone's sessions.
Everything bullpen persists is resolved from the process's home directory:
Store::default_path()returnshome_dir()/.bullpen/bullpen.db, and the credential store sits beside it at~/.bullpen/auth.json. There is no way to point either somewhere else.That is fine for a human at a terminal and fatal for anything that supervises bullpen.
Why now
Scoping a jig runtime adapter for bullpen surfaced this as a hard blocker. jig composes the complete subprocess environment for each agent phase — a role's env allowlist plus an ephemeral HOME — deliberately, so a phase cannot reach the operator's environment.
Run bullpen under that and every phase gets a brand new, empty store. Resume — the entire reason to wrap bullpen instead of a stateless CLI — silently stops working.
Worse, it fails late. The first send succeeds and mints a session id. The second send passes that id to
run -ragainst a store that has never seen it. The error surfaces two phases into a run, nowhere near the cause.What
Resolve the bullpen home from
BULLPEN_HOMEwhen set, falling back to$HOME/.bullpenwhen not.Scope it to the whole directory, not just the database —
auth.jsonhas the same problem, and one concept is easier to reason about than two:BULLPEN_HOME=/path→ store at/path/bullpen.db, credentials at/path/auth.json$HOME/.bullpen/…Notes
--storeflag through every subcommand is more surface for the same result. A flag can come later if a human wants one; the env var is what unblocks the adapter.BULLPEN_HOMEunset nothing changes, so no existing store moves and no migration is needed.$HOME/.bullpen, so a future refactor cannot quietly relocate everyone's sessions.