Remote and ephemeral machines

anyray-connect configures the machine it runs on — but coding agents often run somewhere else: a devcontainer, a Codespace, an SSH host, a CI job. Every one of those is one headless command away from routing through your gateway.

Two properties make this work, and they hold on every path below:

• Headless never hangs. With --yes, a run never prompts; without it, a non-TTY run fails fast with an instruction instead of blocking a postCreateCommand forever.
• Sign-in needs no local browser. Enrollment polls the gateway — connect prints a URL and a code, you open the URL in any browser on any machine, and the remote CLI completes on its own.

Devcontainers and Codespaces

1

Store the enrollment link as a secret

Add your org's SSO link (or a shared enrollment link) as a Codespaces secret or devcontainer secret named ANYRAY_SSO_LINK — secrets arrive as environment variables, so the link never sits in a committed file.

2

Bootstrap in postCreateCommand

.devcontainer/devcontainer.json

{
  "postCreateCommand": "curl -fsSL https://app.anyray.ai/connect.sh | sh -s -- --sso \"$ANYRAY_SSO_LINK\" --yes"
}

The installer puts anyray-connect on PATH, enrolls, and applies — no prompt can fire.

3

Verify

Run anyray-connect status inside the container.

What "configured" means in a container

status and doctor print an Environment section naming the detected backend (dev container, Codespace, or SSH). In containers there is no launchd or systemd --user, so connect skips the OS auto-refresh schedule and the loopback daemon on purpose — Claude Code re-mints its key through the apiKeyHelper, and other tools refresh whenever anyray-connect runs. That skip is expected, not a failure.

Personal machines with dotfiles: the same one-liner works in a Codespaces dotfiles install script.

SSH remotes

SSH into the host and run the normal installer command — enrollment prints the sign-in URL and code, which you open in the browser on your laptop:

curl -fsSL https://app.anyray.ai/connect.sh | sh -s -- --sso https://app.anyray.ai/sso/tnt_example --yes

An SSH host is a real machine, so unlike containers the systemd --user auto-refresh schedule installs normally.

Commit the routing with the repo: --project

Instead of configuring each machine, commit the routing so every checkout of a repo routes — including checkouts on machines you never touch:

anyray-connect --project --yes

This writes two committable files in the current repo:

File	What it carries
.claude/settings.json	ANTHROPIC_BASE_URL pointing at the gateway, plus an apiKeyHelper (anyray-connect print-key) that resolves each developer's own key on demand.
.codex/config.toml	An Anyray model_providers block with command-backed auth — the same helper, no serialized key.

The files are machine-independent by construction: no credential (each machine's key comes from the helper), no identity (spend attributes to each developer's own enrolled key — never to whoever ran the command), and no absolute paths (the helper is PATH-resolved). Each consuming machine still needs anyray-connect installed and a one-time enrollment — which is exactly what the devcontainer bootstrap above provides.

Project config always uses the org API lane

Subscription seat pass-through is a per-developer, per-machine lane (seat OAuth plus the local key-refresh daemon) and cannot ride a committed file. A checked-in project config routes that repo's Claude Code and Codex through org API billing on every machine that opens it — that's why the command asks before writing.

anyray-connect --project --revert removes exactly what was written, preserving any other settings in those files.

CI jobs

For CI that should route through the gateway, enroll the job as a service key and use the same headless bootstrap — --yes is appended automatically when there's no terminal. Scope the run with --tools if the job only needs the SDK env, and remember CI containers behave like devcontainers: no OS schedule, helper-based refresh.

Hosted cloud agents

Codex cloud tasks, Cursor cloud agents, Devin, Claude Code on the web, and the Copilot cloud agent run on vendor infrastructure — their model calls never leave the vendor's backend, so machine config cannot route them (verified against each vendor's docs, July 2026):

Hosted agent	Env/secret injection into the sandbox	Its own inference redirectable?
OpenAI Codex cloud	Yes — per-repo environments, setup scripts	No
Cursor cloud agents	Yes — dashboard secrets, environment.json	No — curated models via Cursor's backend
Devin	Yes — org secrets, YAML blueprints	No — "does not currently support third-party LLM API keys"
Claude Code on the web	Yes — cloud environments (no secrets store)	No — inference rides an Anthropic-bound channel, even with network access off
Copilot cloud agent	Yes — Agents secrets, copilot-setup-steps.yml	No — endpoint pinned to api.*.githubcopilot.com

Every vendor lets the sandbox reach your gateway (egress allowlists), but the agent's own model client is operated by the vendor outside the configurable path. Spend from these agents is billed by the vendor and is not visible to Anyray's spend store.

Hosted-agent coverage

The one partial opening today is the Copilot cloud agent on self-hosted runners, where inference traffic transits your own network. If hosted-agent visibility matters for your org, tell us — it shapes what we build next.