carlos / platform Public

No way to stage a sidecar from off-box: the activator reads <host>-sidecar.env, but nothing writes it Feature Request open

Migrated from github.com/carlosframework/platform issue #192, opened 2026-08-14. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".

Still outstanding: No CLI or API door writes <host>-sidecar.env, so a sidecar cannot be staged from off-box.

---

The gap

The sidecar co-spawn is complete and good on the running side — spawn after healthy, SIGTERM first at sleep, backoff restart, and SidecarHeader so the sidecar's own long-lived connection neither counts as activity nor wakes a sleeping instance. Enabling one is defined as a file existing:

// HasSidecar: a host has a sidecar iff its sidecar EnvironmentFile exists.
func (b *ExecBackend) HasSidecar(rt registry.Route) bool {
	_, err := os.Stat(b.sidecarEnvPath(rt.Host))   // <DataDir>/<host>-sidecar.env
	return err == nil
}

Nothing writes that file. Config sync refuses the name outright — internal/appconfig/syncexec.go: "<host>.env and <host>-sidecar.env are other owners' files and are never candidates" — and carlos env set writes <host>.config.env, which the sidecar never reads. grep -rn sidecar finds nothing at all under internal/console/, internal/provision/, or the CLI.

So the only way to enable a sidecar is to create a file on the box, which is the one thing CLAUDE.md's own rule says not to do:

> If a day-to-day task has no API/CLI command, that is a product gap, not a > license to drop to AWS.

This is that, exactly — and with the same shape as the 2026-08-06 example already recorded there (carlos instances listing only via the local registry).

Concretely, what we can't do

Eleven's bots are ordinary E2EE members whose device is a machine the operator runs — on our own fleet, a co-spawned sidecar per instance, which is the design CARLOS's was generalised from (backend_exec.go says so: "Eleven's <host>-bot.env, renamed"). Our binary already answers to sidecar run. Every CARLOS space we place is therefore bot-less, and will stay that way until this file can be written from off-box.

Possible shapes

  1. carlos instances sidecar -app <a> -host <h> KEY=VAL… — a sibling of instances create, writing a per-instance record the reconciler materializes. Fits the "placing an instance is a data write" model, and gives per-instance config a door it doesn't have today.
  2. A reserved environment bundle name whose merge target is <host>-sidecar.env rather than <host>.config.env. Cheapest, but overloads a name.
  3. A sidecar block on the instance record itself, so a space arrives with its sidecar rather than acquiring one.

(1) reads most like the rest of the system to me. Happy to send a PR.

Note on the values

A sidecar's env carries real credentials (for us: a bot's one-time invite and an ANTHROPIC_API_KEY), so whichever door this becomes should ride the sealed path — which needs #190 first.

A concrete use for this from ips: rendering PDFs. ips's documents and reports are drawn by a hand-written Go renderer (internal/report/pdf), because a release is --kind binary or --kind static and there's nowhere to run a second process such as a headless browser beside the app.

A sidecar staged from off-box would let an app ship a renderer (or a virus scanner, or a converter for a format with no Go library) as a supervised process next to it, reachable on a socket. From the outside that's the whole of what's missing; the activator reading <host>-sidecar.env suggests most of the mechanism already exists.

--- Filed from the ips repository (Turnkey's insolvency practice system, built on rastrillo v0.26.0 and deployed on CARLOS), where this was worked around. Paths without a repository prefix are in ips.