Setup profiles: give a new environment the CLIs, agent config and sign-ins of the one you already work on

[OmarAlex24]

Problem

A new environment starts bare. A devbox you just paired, or a sandbox from #27949, has T3 and a provider CLI, but none of what agents use on your main machine: the CLIs they call (gh, a cloud provider's CLI, psql), the harness config (CLAUDE.md/AGENTS.md, skills, subagents, plugins, MCP servers), or the sign-ins those need. Agents still run there, but they can't query what they query locally, and the results get worse.

Today the only fix is to set the machine up by hand. For a persistent devbox that's annoying once. For sandboxes it happens on every create, or you snapshot a template that goes stale as soon as you add a skill.

Proposal

Settings → Environments → Setup profile, owned by one environment you pick as the source:

1. Detect. T3 scans the source and lists what it finds, grouped as:
   • Agent config: instruction files, skills, subagents, commands, enabled plugins, and MCP server definitions, per provider.
   • CLIs: detected from a known list, plus any you add, with their versions.
   • Sign-ins they need: shape only. Names, never values.
2. Choose. You tick what goes into the profile. T3 saves the selection, not a copy, so the profile picks up later changes on the source.
3. Apply, depending on the target:
   • Sandbox: on every create. Saving a template bakes in the CLIs. Agent config is copied fresh on each create because it changes often.
   • Persistent environment (devbox, paired machine): a full apply the first time. After that, a check compares the target with the profile and shows what drifted. You apply only the differences, and T3 never overwrites edits made on the target without asking.

Secrets are never copied by value by default. Each sign-in is either:

• entered once per target into the existing secret store, or
• for sandboxes, minted per sandbox and revoked on delete, as Provision sandbox environments from Settings (Boat, Daytona, Vercel, Upstash, Celesto + any driver) #27949 already does for the Claude hub key, GitHub and Tailscale.

MCP servers keep only their URL or command, plus the header names.

CLIs install through small, idempotent recipes (check, then install). A built-in recipe exists for common tools, and you can write your own for anything else. This is not a package manager.

How it relates to existing threads

• Provision sandbox environments from Settings (Boat, Daytona, Vercel, Upstash, Celesto + any driver) #27949: sandbox create applies the profile, and "save as template" runs the CLI layer before the snapshot. With this, a sandbox is actually ready to work, not just reachable.
• Environment-level MCP servers (and later rules/skills) shared by every provider and account #14118: complementary. If T3 gets environment-level MCP servers, the profile carries that list instead of each harness's own files.
• [Feature]: Abstract skills and plug ins across all providers #6987 / [Feature] Manage skills and agents from T3, route to providers via symlinks #7334: they decide which skills and plugins exist. This decides which environments get them.
• Sync environment settings across connected devices automatically #27403 / A rule for which settings the client owns and which the environment owns #19593: those are about T3's own settings. This is about the machine's setup: tools, harness files and sign-ins.

Scope for a first version

• Claude and Codex config files, MCP definitions, CLI recipes, and sign-in prompts.
• Out of scope: syncing T3 settings, two-way sync, and other providers until the shape is agreed.

Questions for maintainers

1. Does this belong in T3, or should it stay a user-side script that sandbox create calls as a hook?
2. If it fits, should it land after the core of Provision sandbox environments from Settings (Boat, Daytona, Vercel, Upstash, Celesto + any driver) #27949, as its "ready to work" step?

I'm prototyping this as a user-side script on my own devbox first, and will post what works and what doesn't here before opening anything.

[SebastiaanBoon]

+1 on the problem. One thought on the "instruction files" part of the profile: copying CLAUDE.md or AGENTS.md to every new environment works, but each copy starts drifting the moment you edit one of them. The check-and-apply step you describe handles that well for persistent machines. For sandboxes that get created and thrown away, it may be easier to not copy the instructions at all.

What has worked for me is keeping the rules, a short profile and per-project notes as plain markdown files in one cloud folder, and letting each environment read them through a remote MCP connector. A new devbox or sandbox then only needs the connector URL in its MCP config, and it sees the same rules as every other environment without a sync step. If you edit a rule once, all of them pick it up on the next session.

That only covers the instruction and context layer. It does nothing for the CLIs or the sign-ins, so your detect and apply flow is still needed for those. But it could shrink the "agent config" group in the profile to one MCP entry plus a short pointer in AGENTS.md.

Disclosure: I built Cloud Alter Ego, which does this (files stay in your own OneDrive, Google Drive, Dropbox, GitHub or Azure DevOps, behind a remote MCP connector). Docs: https://cloudalterego.cafeboon.com/docs.html and the open source template: https://github.com/SebastiaanBoon/cloud-alter-ego. The same layout works with a plain git repo and no connector at all if you prefer to avoid a service.

[Pavel-Tk]

One tip: keep one shared file and import it in each CLAUDE.md with @~/path/to/file. The docs say imports from your home directory work.

The hard part is that the file still has to be synced to every machine, and Codex's AGENTS.md is a separate copy to keep up to date.

At Substrate we built our memory to solve this: all your agents read one memory, and you choose what each one sees.

Which environment drifts the most for you?

https://trysubstrate.co/l/a2gh