Idea: a remote backend for kirocrew pod (run isolated instances off-box)

[SaRedfiche]

Idea: a remote backend for kirocrew pod (run the isolated instance off-box)

Floating this in Ideas rather than as a feature request, because the approach is the open question — I want to agree on direction before anyone writes code. (CONTRIBUTING.md + the issue-template config both point exploratory ideas here.)

The problem

kirocrew pod is great for standing up a throwaway, full-stack gateway per worktree — own port, own KIROCREW_HOME, resource-capped, reclaimed on down, "kubectl for local worktree test rigs." But it is local only: start_pod/stop_pod dispatch to launchd (macOS) or systemd --user (Linux), so every pod runs on the developer's own machine. That caps how many pods can run at once, ties them to one host's resources, and means a laptop asleep or a Mac without systemd can't participate.

The natural next step is running a pod on a remote host — an ephemeral container/pod or a cloud dev environment — behind the same pod CLI verbs.

What already exists to build on

The seam is mostly in place. The launchd work already turned the backend into a dispatch, not a hardcode: a small set of functions in pod/runtime.py (require_backend, is_active, unit_state, recent_journal, active_names, start_pod, stop_pod, install_backend) branch on the host's service manager, and launchd.py is a sibling module implementing that surface. The CLI (pod/cli.py) never names a service manager — it only calls runtime.* — so a third backend behind those same functions needs no CLI changes. PodConfig (pod/config.py) is the natural place for a backend selector, and environment_vars() already serialises the pod plane in a backend-neutral way ("selection separated from serialisation, so the two backends don't drift").

So this is extend a proven primitive, not build a new one.

The open questions I'd like input on

1. Target runtime. Ephemeral Kubernetes pods, a cloud dev environment (e.g. an EC2/managed dev desktop), or one interface over both? This is the biggest fork — it decides what a remote.py backend actually shells to.
2. CLI surface. Preserve the existing up/down/ls/status/logs verbs (add a --backend remote / KIROCREW_POD_BACKEND=remote selector), or a distinct command family? Preserving the verbs seems clearly better, but flagging it.
3. Auth to the remote gateway. Today mint_token and health assume loopback 127.0.0.1:{port} — they read the pod's .local_secret and POST /api/token/local. The cheap path is to port-forward the remote gateway to loopback so those stay unchanged; the fuller path is a real remote-auth hook. Which fits the project's security posture?
4. First milestone. I'd propose the smallest end-to-end proof: one remote pod that boots, serves /api/*, mints a token, and is reclaimed on down — deferring scale, cost controls, and multi-pod scheduling to later.

Why I'm asking first

A remote executor is a meaningful new subsystem, and the pod teardown/lifecycle code is carefully guarded (cgroup drain ordering, the ExecStopPost race, zero-residue verification). Before extending it I'd like a maintainer's read on (a) whether a remote backend is something the project wants upstream at all, and (b) which of the runtime/auth directions above fits the roadmap. Happy to write the design doc and the first-milestone PR once there's a direction.

Prior art / context: this maps to the "remote execution in isolated environments (ephemeral k8s pods or cloud desktops) with secure token management and environment isolation" capability that keeps coming up in agent-platform discussions.