Two things, both from today's live incident.

THE SPLIT REGISTRY. _pod_registry_path() fell back to ~/.coderai whenever
config_manager was not initialised in the calling process. The container's
launcher puts the real config dir one level deeper — it exports
XDG_CONFIG_HOME="$CODERAI_CONFIG_DIR" and uses "$CODERAI_CONFIG_DIR/coderai",
which is also where platform_paths.user_config_dir() lands. So a process with
the config manager wrote one registry and a process without it read another,
and the pods each owned were orphans to the other. That is what made the
documented mutual-kill loop recur: pod created 19:24:56, terminated as
untracked 19:24:57. The fallback is now the same XDG-aware path the launcher
computes, and the resolved path is logged once — a registry that splits
silently is invisible until it costs a GPU.

CLIENT-FORCED TEARDOWN. `pods: 0` released a client's lease but gave nothing
back: the pods then waited out scale_down_after_s, or idle_timeout_s before
that. The automatic path is slow on purpose — it infers from a momentary
reading, and a cold pod costs minutes to replace — but a client that has just
finished a batch is not inferring. `teardown: true` sheds the surplus at once,
skipping both the window and the one-per-pass limit, and answers with what
happened. It still cannot scale through the operator's min_pods, and a pod with
requests on it drains rather than dying under them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PxYHWbCAjjjD7A1rhFKtaW