Spawned CLI workers and PWD
childprocess.spawn() sets a child's working directory but copies PWD from the parent environment verbatim — a shell updates PWD on every cd, Node does not. So a CLI worker spawned into a git...
child_process.spawn() sets a child's working directory but copies PWD from the parent
environment verbatim — a shell updates PWD on every cd, Node does not. So a CLI worker spawned
into a git worktree used to inherit a PWD still naming the orchestrator's own directory. Any CLI
that resolves its project root from $PWD rather than getcwd() then operated on the WRONG
repository, while every Cyberine-side check looked correct — and these workers run with
auto-approve, so it would have edited that repo unprompted.
buildScopedChildEnv() now rewrites PWD to the spawn cwd, last, so it wins over both envScrub
and envSet. Nothing legitimately needs to hand a worker a PWD contradicting the directory it
runs in. Pinned by npm run selftest:cli-pwd-sync, positive-controlled.
This was found through the opencode2 worker, which has no --dir flag to override the wrong
inference. The v1 opencode worker was never affected for exactly that reason, which is also why
this went unnoticed: every CLI worker in the fleet either passed an explicit directory or happened
to use getcwd().
Muse via the raw Meta Model API (loop-muse-build)
A SECOND, unrelated way to reach the same models: a key-only LoopAgentAdapter against Meta's OpenAI-compatible endpoint, with no muse binary and no CLI login. It is registered but ships retired,...
Retiring a worker — RETIRED_WORKERS
A worker whose account is unfunded or ineligible is not the same as a worker with no credential, and Cyberine used to have no way to say so. An out-of-balance account still holds a VALID key, so...