Move from Conductor Cloud to your own always-on VM
Conductor Cloud closes Nov 20. Keep your agents running on a VM of your own.
Shelley handles the setup. About 20 minutes.
Prefer a terminal?
curl -fsSL https://exe-staging.dev/deploy/migrate-conductor-cloud/prompt.txt | ssh exe.dev new --prompt=/dev/stdinConductor is joining Meta, and Conductor Cloud, its hosted workspaces for Claude Code and Codex, is closing. On November 13, 2026 it goes read-only, and on November 20 it shuts down and Conductor begins deleting Cloud user data. The local Mac app keeps getting models and critical fixes until early 2027, then winds down too.
The point of Conductor Cloud was that your agents kept working after you closed the laptop. An exe.dev VM does that, and keeps doing it: it's always on, its disk persists, it reaches your repositories through the GitHub integration and your models through the LLM integration, so no tokens or API keys live on it. This page gets your work out of Conductor Cloud before the deadline, then sets up T3 Code, an open-source workbench that runs each agent thread in its own Git worktree, the way Conductor did.
What you get#
- Claude Code and Codex connected to exe.dev's LLM integration, with no API key on the VM.
- T3 Code running as a background service on port 3773, back after a reboot.
- REPO cloned into
~/<name>through the GitHub integration and added to T3 Code as a project. - A
t3.jsonin the clone that carries over the repository's Conductor setup script, if it has one, ready to import in T3 Code's Actions menu. - A setup-check thread in T3 Code that answers
OK.
What's running, and where
https://my-agents.exe.xyz:3773/
T3 Code in your browser or phone, after a one-time pairing link
https://my-agents.exe.xyz:3000/
A dev server an agent starts, on any port from 3000 to 9999
ssh my-agents.exe.xyz
Your terminal, for pairing links, .env files and upkeep
Deploy with Shelley#
Click Deploy and Shelley will set up Agents from Conductor Cloud on a new VM, then check that it works. No config-file wrangling required.
Have these ready; Shelley asks for them:
REPO: a GitHub repository you used in Conductor Cloud, as owner/name; add the others the same way afterwards
Prefer a terminal?
curl -fsSL \
https://exe-staging.dev/deploy/migrate-conductor-cloud/prompt.txt \
| ssh exe.dev new --prompt=/dev/stdinWhat Shelley is told
REPO=<fill-this-in>
Set up Agents from Conductor Cloud on this VM by following the exe.dev recipe at https://exe-staging.dev/deploy/migrate-conductor-cloud.md from top to bottom.
The values at the top of this message are mine:
- REPO: a GitHub repository you used in Conductor Cloud, as owner/name; add the others the same way afterwards
Ask me for any that still say <fill-this-in> before you need them.
The recipe's example VM name is my-agents. This VM's name is the output of `hostname`: use it wherever the recipe writes my-agents. Skip the step that creates the VM; you are on it.
You are done when all of these are true. Check each one yourself:
- Claude Code and Codex connected to exe.dev's LLM integration, with no API key on the VM.
- T3 Code running as a background service on port 3773, back after a reboot.
- REPO cloned into `~/<name>` through the GitHub integration and added to T3 Code as a project.
- A `t3.json` in the clone that carries over the repository's Conductor setup script, if it has one, ready to import in T3 Code's Actions menu.
- A setup-check thread in T3 Code that answers `OK`.
Read the whole recipe, including the closed details. Follow "Set up by
hand" from "Install T3 Code" to the end, as exedev; the walkthrough
above it is for the owner. If `exeuntu configure` reports an existing
user config, leave it alone. Do not create a pairing link: they expire
in five minutes and work once. Leave public sharing off.
REPO is a GitHub repository; turn a URL into owner/name. Clone it
through the GitHub integration into ~/NAME. If that fails with "not
found" or a 403, give the owner the integration command from "Get your
code", with this VM's name, and wait for them; install the rest
meanwhile.
Look for a Conductor setup script in .conductor/settings.toml or
conductor.json at the repository root. If there is one, write t3.json
as "Setup and run scripts" says, translating CONDUCTOR_ variables; do
not commit it and never push. If the owner's setup script lives only
in Conductor's Cloud Computer settings, say that they need to paste it.
Don't copy or invent .env files: the owner brings those.
Finish by giving the owner the `ssh ... t3 pair` command from "Open T3
Code" with this VM's name, the integration command for their other
repositories, and the list in "Before November 13" if it isn't
November 13 yet.
Finish with the URLs I should open.
Also at /deploy/migrate-conductor-cloud/prompt.txt. The recipe it follows is /deploy/migrate-conductor-cloud.md.
Before November 13#
After November 13 you can still read and export, but agents can't run, so do these while they still can. In Conductor, for every cloud workspace you want to keep:
- Push the branch. Each workspace is a Git branch. Ask its agent to
commit everything, including new files, and push the branch to GitHub,
or do it yourself in the workspace's terminal:
git add -A && git commit -m "WIP from Conductor" && git push -u origin HEAD. - Copy what Git doesn't push. Files in
.gitignore, such as.env, and notes in the workspace's.contextfolder stay behind. Copy any you need. - Or transfer it to local. Right-click the workspace and choose Transfer to local to move it and its chats to your Mac. Then push its branch from there, as above.
- Export your data. In Settings → Account → Export data, download everything Conductor has for you. Keep the download.
- Write down your Cloud Computer settings. The setup script for each repository and the install-software script are in Conductor's organization settings: copy their text. Conductor hides environment variable and secret values after you save them, so get those from where they came from (your password manager, or each service's dashboard).
Warning
Conductor deletes Cloud data from November 20. A branch on GitHub and your export are what survive; check that
git ls-remote originon your computer lists every branch you meant to keep.
Conductor's Cloud FAQ and changelog have the details, and humans@conductor.build answers questions.
How the move works#
| In Conductor Cloud | On your exe.dev VM |
|---|---|
| A sandbox per workspace, asleep after 20 idle minutes and stopped after 23 hours 50 minutes | One VM, always on, with every repository and worktree on a disk that persists |
| Workspaces from your GitHub repositories | Clones through the GitHub integration, with no token on the VM |
| A workspace per branch, as a Git worktree | A T3 Code thread per branch, in its own Git worktree |
| The Cloud Computer's setup script | A T3 Code action that runs on every new worktree |
| Run scripts and forwarded ports | Actions, and any port from 3000 to 9999 at https://my-agents.exe.xyz:PORT/, private to you |
| Conductor's model access | Claude Code and Codex through the LLM integration, billed to your exe.dev account |
| The Mac app and the iOS app | T3 Code's web app, in your laptop's and your phone's browser |
Chats don't move: no tool here imports Conductor's history. Your code, your branches and your setup do.
Pick a workbench#
T3 Code is the default here because it runs entirely on the VM, gives every thread a worktree, runs setup scripts on new worktrees like Conductor, and works from any browser, phone included. Several others work on an exe.dev VM just as well, and each has its own page:
- T3 Code: open source, MIT. A web app served by the VM; Claude Code and Codex. Its authors list Conductor among its inspirations. Followed below.
- Orca: open source, MIT. A desktop app on your Mac,
Windows or Linux computer, with worktrees on the VM over SSH. It offers
the
setupscript from aconductor.jsonas its own setup script, and shows worktrees made outside Orca. It doesn't read.conductor/settings.toml. - Paradev, formerly Superset: a desktop app with the VM as a remote host over SSH. It imports existing Conductor worktrees, and has its own guide for Conductor Cloud users. Remote hosts need a paid Paradev plan.
- Paseo: open source. A daemon on the VM with desktop, web, iOS and Android apps, for Claude Code, Codex and OpenCode.
- OpenChamber: open source, MIT. A web and phone workspace for OpenCode, served by the VM, with worktrees and multi-run.
- Herdr: one window for all your agents, telling you which needs you; the VM joins its sidebar over SSH.
If you only want one agent running remotely and don't need parallel worktrees, Codex remote control steers Codex on the VM from the ChatGPT app, and a Claude Code self-hosted runner runs claude.ai/code sessions on it. Or skip the workbench: Claude Code and Codex run on the VM in a terminal.
The moving steps below, pushing branches, cloning through the GitHub
integration and carrying over .env files, are the same whichever you
pick.
Get your code#
Create the VM, or click Deploy above and skip to the next section. On your computer:
ssh exe.dev new --name=my-agents
A new VM has 2 CPUs, 8 GB of memory and a 25 GB disk. Conductor Cloud gave every workspace 8 CPUs and 16 GB; for several agents building at once, grow the VM as far as your plan allows:
ssh exe.dev resize my-agents --cpu=8 --memory=16GB --disk=100GB
Give the VM each repository you used in Conductor. With your GitHub account linked to exe.dev, on your computer:
ssh exe.dev integrations add github --name app --repository you/app --attach vm:my-agents
Then clone it on the VM. Every branch you pushed comes with it:
git clone https://github.int.exe.xyz/you/app.git ~/app
git -C ~/app branch -r
Copy the gitignored files you saved, such as .env, from your computer:
scp .env my-agents.exe.xyz:app/.env
Agents can push branches and, with GH_HOST=github.int.exe.xyz, open pull
requests with gh; pushes show up as the exe.dev GitHub App unless you add
the integration with --act-as-user. Add --readonly if agents should
only read.
Setup and run scripts#
In Conductor, a setup script ran in every new workspace, from
.conductor/settings.toml, a legacy conductor.json, or, in the cloud,
the Cloud Computer settings. T3 Code calls these actions; one marked to
run on worktree creation is the same thing. Put them in a t3.json at the
repository's root:
{
"$schema": "https://t3.codes/schema/t3.json",
"defaultThreadEnvMode": "worktree",
"scripts": [
{
"name": "Setup",
"command": "npm install && cp \"$T3CODE_PROJECT_ROOT/.env\" .env",
"icon": "configure",
"runOnWorktreeCreate": true,
"async": false
},
{
"name": "Dev server",
"command": "npm run dev -- --host 0.0.0.0 --port 3000",
"icon": "play"
}
]
}
"async": false makes the agent wait for setup to finish, and
defaultThreadEnvMode starts every new thread in a worktree. Translate
Conductor's variables as you go:
| Conductor | T3 Code |
|---|---|
CONDUCTOR_ROOT_PATH, the main checkout |
T3CODE_PROJECT_ROOT |
CONDUCTOR_WORKSPACE_PATH, the workspace |
T3CODE_WORKTREE_PATH, also the working directory |
CONDUCTOR_PORT |
none: pick a port from 3000 to 9999 |
Files to copy, .worktreeinclude |
a cp in the setup command |
| An archive script | none: run it as an action by hand |
If your setup script is a file in the repository that reads Conductor's
variables, call it with them set:
"command": "CONDUCTOR_ROOT_PATH=\"$T3CODE_PROJECT_ROOT\" ./script/setup.sh".
T3 Code doesn't apply t3.json scripts by itself. Open the project's
Actions menu: they're listed under From t3.json, and one click on
each imports it. Commit t3.json to share it with your team, or leave it
uncommitted; the imported actions stay in T3 Code's settings either way.
A dev server on the VM is at https://my-agents.exe.xyz:3000/ (or whichever
port it uses, from 3000 to 9999), private to you through exe.dev's
HTTPS proxy. Have it listen on 0.0.0.0, not localhost.
Open T3 Code#
On your computer, make a one-time pairing link, and open it within five minutes:
ssh my-agents.exe.xyz 'echo "https://$(hostname).exe.xyz:3773/pair#token=$(~/.local/bin/t3 pair --label laptop | sed -n "s/^Token: //p")"'
exe.dev asks you to log in, then T3 Code pairs the browser. To pick up a
Conductor branch, start a new thread, choose New worktree under the
message box, and pick the branch, such as origin/you/login-redirect, from
the branch menu beside it. T3 Code makes a fresh worktree from that branch,
runs your setup action in it, and only then starts the agent.
T3 Code names the worktree's branch itself, starting with t3/. To keep
pushing to your Conductor branch, ask the agent to push with
git push origin HEAD:you/login-redirect, or open the pull request from the
new branch.
For your phone, other repositories, backups and updates, follow the T3 Code page: it's the same setup.
Ask Shelley#
Every exe.dev VM also has Shelley, exe.dev's own
coding agent, at https://my-agents.shelley.exe.xyz/. Ask it to translate a
Conductor setup script into t3.json, clone your other repositories, or
find out why a setup action fails.
The nuts and bolts#
Set up by hand
Create the VM#
On your computer, create the VM and give it your first repository, as in "Get your code", then connect:
ssh exe.dev new --name=my-agents
ssh exe.dev integrations add github --name app --repository you/app --attach vm:my-agents
ssh my-agents.exe.xyz
Install T3 Code#
On the VM, connect Claude Code and Codex to the LLM integration, install T3 Code with its official installer, and run it as a service on port 3773:
exeuntu configure claude
exeuntu configure codex
curl -fsSL https://t3.codes/install.sh | sh
export PATH="$HOME/.local/bin:$PATH"
mkdir -p ~/.t3
printf 'T3CODE_HOST=0.0.0.0\nT3CODE_PORT=3773\n' > ~/.t3/service.env
t3 service install
Add your repository#
Still on the VM, clone the repository and add it to T3 Code:
git clone https://github.int.exe.xyz/you/app.git ~/app
t3 project add ~/app
If the repository has a Conductor setup script, write ~/app/t3.json as
"Setup and run scripts" says.
Check it#
The service status says installed, port 3773 is listening, and a one-line
task through T3 Code prints OK:
t3 service status
ss -ltn | grep 3773
cd ~/app && t3 thread start --provider claudeAgent --model haiku \
--title "Setup check" --wait . "Reply with exactly: OK"
Something not working?
git clone says not found or 403. The VM has no integration for that
repository yet, or it's attached to another VM. Run the integrations add
command from "Get your code" with this VM's name.
A branch from Conductor isn't in the branch menu. It wasn't pushed. If
the workspace still exists in Conductor, push it, then run git fetch in
the clone on the VM.
The setup action didn't run in a new worktree. Check that it's imported
(it shows above From t3.json in the Actions menu, not under it) and has
runOnWorktreeCreate set.
.env is missing in worktrees. Git doesn't copy ignored files into new
worktrees. Put the file in the main checkout (~/app/.env) and copy it in
the setup action, as above.
T3 Code shows Pair with this environment. The token got lost on the way
through exe.dev's login. Paste the 12 characters after token= into the
box, or make a fresh link. More on the T3 Code page.
Frequently asked questions#
When exactly does Conductor Cloud stop?
Conductor's announcement gives three dates. On November 4, 2026, sign-ups and downloads stopped. On November 13, Conductor Cloud goes read-only: you can read old chats and export data, but not send new messages, and active subscribers get a refund. On November 20, Cloud shuts down and Conductor begins deleting Conductor Cloud user data.
Does the local Conductor app keep working?
For now. Conductor says the Mac app gets new models and critical bug fixes until early 2027 and then winds down, and that all Conductor user data is deleted when it shuts down. Transferring cloud workspaces to local buys you time, not a permanent home.
Can I bring my Conductor chats over?
Not into T3 Code or the other tools on this page: none of them imports Conductor's chat history. Export your data from Conductor to keep a copy, and transfer workspaces to local if you want to keep reading them in Conductor until it winds down. The code is what moves: every workspace is a Git branch.
Do I need a separate VM for every workspace?
No. Conductor Cloud gave each workspace its own sandbox; here one VM holds all your repositories, and each thread gets its own Git worktree on it. If you want harder walls, between clients or projects, create a VM for each. Your plan sets how many VMs, CPUs and how much memory you get, and ssh exe.dev resize grows a VM.
Can I use my Claude or ChatGPT subscription instead of the LLM integration?
Yes. On the VM, undo what exeuntu configure set up and sign in with claude auth login or codex login, then restart T3 Code. The T3 Code page has the exact steps.
How much does it cost?
T3 Code is free and MIT-licensed. The VM is part of your exe.dev plan, and model usage through the LLM integration is billed to your exe.dev account; exe.dev keeps a list of models and prices.
Updated Nov 7, 2026 · tested end to end Nov 7, 2026 · Markdown · manifest.json · Something wrong? Tell us