carlos / platform Public

Ask: a member-run, one-off command against ONE instance of an app, without root on the box: carlos run --app <a> --instance <host> -- <argv…>.

Why

On 2026-10-06 a titogo session copied a past event from Tito Pro into a live account and imported 22,462 check-ins (titogo PR #4048, "importer: copy one past event into a live account, and import check-ins scanned by another system"). Every step that touched the box went over aws ssm send-command as root on carlos-tito-ie:

• running the app's own binary against the instance's database (titogo import event …, titogo import checkins …);
• reading a credential the app's config already holds (the Pro reader DSN);
• staging the input file on the box through S3 presigned URLs.

The canary recipe has the same shape: titogo add (registry), auth grant, seed, all over SSM as root.

Two of Tito's team (Doc and Vicky) are blocked from this kind of work today. Handing them SSM would mean root on a box shared by every tenant, with every secret readable. They can already sign in to the console as members of the tito account. What's missing is a platform door for "run this app's command against that instance".

What it should do

• Who runs, and as whom. The release binary the instance follows (or --version), run as the same identity and sandbox as the instance itself: nested layout, its own directory bound in, nothing else. Never root, never the agent.
• What it sees. The instance's database and data directory, and the app's config bundle for that instance's environment, exactly as the instance is started (docs/site/cli.md § "What an instance is started with"). Secrets go in through the environment, never echoed.
• Who may. Gated by account role (an owner/admin capability, or a per-app grant). Allowed per app: it is the app's own binary, so the app decides what its subcommands do.
• Input files. --file <local path> uploads a file into a scratch directory the command can read ($CARLOS_RUN_DIR), deleted afterwards. Our check-in CSV was 600 KB; a 64 MB cap would cover the realistic cases.
• Output. stdout and stderr stream back to the terminal, and the exit status becomes carlos run's own.
• Recorded. An audit row in the console: who, app, instance, argv, version, start, end, exit status. Output is not stored by default. A future --record could keep it.
• Concurrency with the live instance. The command opens the same SQLite file while the instance runs (WAL), exactly as titogo's importer does today through its own IMMEDIATE transactions. The platform need not stop the instance. A --stopped flag (stop, run, start) would be a later nicety.
• Waking. A hibernated instance's data must be in place; whether that means waking it or only mounting its directory is the platform's call.

Not asking for

• An interactive shell. run is argv only, which keeps it auditable.
• Anything for controld-run (titogo@) instances. Paul, 2026-10-08: those all convert to platform-run (see the companion request on the adoption door), so this only needs to serve platform instances.

Depends on the nested layout being live (#126, tracked in #247). On a flat box, a run would have the same reach as the agent.