Working from a cloud session

A remote coding session uses a fresh clone in a throwaway container. The repository’s AGENTS.md still applies, including the production-data and blocker rules.

Set up the CLI

Install dependencies with bun install --frozen-lockfile and use the checkout’s CLI with bun run apps/cli/src/cli.ts.

Set ARBE_TOKEN in the cloud environment’s secret store to authenticate without changing the stored login. Generate a token at Account → API.

For a stored login, arbe login --token <token> also works without a terminal. With several houses, it leaves the choice to you rather than opening a prompt. Run arbe house select <id> to save the active house in CLI config. For repository probes, always pass --house <id> explicitly, even when an active house is saved.

secret store → ARBE_TOKEN → authenticated CLI command
stored login → CLI config → saved token and active house

Configure checks and network access

The committed schemas define required values; see Environment variables for their ownership and loading rules. Set cloud-session secrets in the environment’s secret store rather than relying on local files surviving a rebuilt container. Do not start a local backstage: it would claim production jobs.

Live proof requires access to Arbe, Supabase, durable streams and the model provider. If the container’s network policy blocks them, report the exact blocker and ask for access. Passing local checks is not a substitute for a required live proof.

Container tool versions and privileges vary. An outdated Bun, missing tool or failed authentication is a blocker, not permission to bypass a guard. Tests that stage an unreadable file must work under root too; mode bits alone cannot force a read failure there.