Conductor Cloud Shutdown: Export Before November 20

Complete and verify Conductor Cloud workspace transfers and terminal-dependent backups before November 13, 2026, as a precaution. Download the account archive before November 20. Preserve unfinished files separately, use local Conductor as a temporary bridge, and rebuild parallel work with Claude Code, Codex, or OpenCode.

Contents
Conductor Cloud Shutdown: Export Before November 20

Complete and verify Conductor Cloud workspace transfers and terminal-dependent backups before November 13, 2026, as a precaution. Download and verify the separate account archive before November 20, 2026. Use Transfer to local for workspaces and Settings → Account → Export data for the archive.

Conductor’s announcement that it is joining Meta confirms that old chats and data export remain available during read-only access. It does not confirm that workspace transfers or Cloud terminals remain available then. Cloud shuts down and deletion of Cloud user data begins on November 20.

For existing users, local Conductor can provide time to finish active work. Treat it as a temporary bridge, not your only backup or a permanent replacement.

Which Conductor shutdown dates matter?

Finish workspace transfers and terminal-dependent backups before read-only access begins. Keep the documented account-export window separate from this precaution. As of 2026-11-10, Conductor’s official timeline is:

DateWhat changesWhat to do
November 4, 2026New users can no longer sign up for Conductor or download the app. Existing Pro users can keep using Pro features free.Plan around your existing installation and account.
November 13, 2026Cloud workspaces become read-only. Old chats and data export remain available, but new messages stop.Finish interactive work beforehand. As a precaution, also complete and verify workspace transfers and terminal-dependent backups before this date.
November 20, 2026Cloud shuts down, and deletion of Cloud user data begins.Complete and verify the separate account export before this date.
Early 2027Local Conductor’s promised period of new models and critical fixes ends, and its wind-down begins.Remove your remaining dependence on the app before the wind-down.

The announcement also promises refunds for active subscribers. Check your billing record separately; the refund promise does not confirm that a payment has reached your account.

For a team migration, use November 12 as an internal completion target. This is a suggested buffer, not an official transfer cutoff. Do not plan around account-export access lasting through the end of November 20.

How to export Conductor Cloud without losing unfinished work

Use both export routes, and save unfinished files independently while the Cloud workspace is accessible. Verify each copy before relying on it. Do not assume the account archive can restore modified, untracked, or ignored workspace files.

Record and save the state of each workspace first

Make a small inventory before moving anything. Record the workspace name, repository, branch, latest commit, open pull request, and person responsible for checking the result.

Pause agent edits and commits while recording the snapshot. While Cloud terminals are accessible, run these checks from each workspace’s repository root. Complete this work before November 13. The shell is Bash:

git rev-parse --verify HEAD
git status --short --branch --untracked-files=all
git diff HEAD --stat

The first command records the current commit. The second shows branch information and changed or untracked files. The third summarizes tracked-file differences from that commit. Git documents these behaviors in its revision, status, and diff references.

Save the complete status output as pre-transfer-status.txt in your independent backup before creating backup folders inside the repository. Keep the full commit ID and branch name with it. For deletions and renames, also record which paths are absent from the final working-tree snapshot.

These commands inspect state; they do not save file contents. Push reviewed commits to an approved remote, and confirm the branch and commit there. Save that remote’s URL without embedded secrets in the inventory. For commits you cannot push, complete the bundle-and-restore check below before moving the workspace. Do not bulk-add secrets or private configuration just to produce a clean status.

Inspect .conductor/settings.toml, .conductor/settings.local.toml, and .context where present. Conductor documents project scripts, local project configuration, and uncommitted handoff notes in these locations.

Record setup commands, required runtime versions, external services, and environment-variable names. Restore secret values through your approved credential store, not through a migration ticket or agent prompt.

Before attempting a workspace transfer, make an independent copy of required unfinished files. One documented route is Sync to a local directory, which mirrors the Cloud workspace into a local folder. After the required files appear, copy them from that folder into separate, approved backup storage.

Preserve relative paths and keep the inventory with the backup. Include required modified and untracked files, and check required ignored files separately. Store sensitive configuration only in locations approved for that data.

Open the copied files and compare their contents with the accessible source. Check the file list against your inventory, including recorded deletions and renames. Do not edit the synced folder or treat it as your only backup.

For a missing small text file, save its complete source contents into a local file at the same relative path. Reopen and compare that copy. If any required file still lacks a verified local copy, stop the workspace move. This includes a binary file that sync omits, such as repository.bundle. Contact Conductor through its announcement while the Cloud workspace is still accessible.

Keep edits paused through backup verification, or refresh the status record and copies after the last change. Complete and verify any terminal-dependent copying before November 13.

Back up commits that cannot be pushed

Save a local Git-history backup before transferring a branch whose commits cannot be pushed. Git’s bundle command can package repository refs and their committed history for offline recovery. Keep the separate unfinished-file copies described above.

Pause new commits and branch updates while taking this snapshot. From the Cloud repository root, run this Bash example with an unused conductor-history-backup directory:

mkdir conductor-history-backup &&
git for-each-ref --format='%(objectname) %(refname)' refs/heads > conductor-history-backup/branches.txt &&
git bundle create conductor-history-backup/repository.bundle --all

Check that branches.txt includes each required branch and its full commit ID from your inventory. Copy the entire folder to approved local storage using the file-copy route above. Keep this copy outside the synced directory, and confirm that repository.bundle itself reached your Mac. Keep pre-transfer-status.txt, the inventory, and the saved files with this backup.

Before transferring the workspace, test recovery from this local copy. Open Bash in the copied conductor-history-backup folder. Use an unused restored.git destination:

git clone --mirror repository.bundle restored.git &&
git --git-dir=restored.git for-each-ref --format='%(objectname) %(refname)' refs/heads > restored-branches.txt &&
git diff --no-index --exit-code -- branches.txt restored-branches.txt &&
git --git-dir=restored.git fsck

The mirror clone restores the refs into a separate bare repository, without a working-tree checkout. The manifest comparison must show no differences. git fsck must report no missing or corrupt Git objects.

Confirm the expected branch names and commit IDs in restored-branches.txt before moving the workspace. Stop if any command fails or a required branch is absent. Resolve the backup problem while the Cloud repository remains accessible.

Keep the bundle, manifests, and unfinished-file copies as private repository data. Repeat this procedure for each repository with unpushed work, and refresh it after further commits.

Transfer one workspace, verify it, then repeat

Complete and verify each workspace transfer before November 13 as a precaution. On your Mac, right-click a Cloud workspace and choose Transfer to local. Conductor’s 0.93.0 release notes describe moving the workspace and its chats to your Mac.

After the transfer finishes, open the local workspace and run the inventory commands again. Compare its branch, commit, pending changes, and file contents with the inventory and independent copies verified before the move. Open both an older chat and the latest conversation.

Check untracked files and project configuration separately. Do not assume that a visible repository proves every file or environment dependency survived.

Restore dependencies using the project’s documented setup procedure. Then run its smallest useful test or build check. Investigate mismatches against your verified remote or bundled Git history and independent file copies. Use the original Cloud workspace for comparison only if it remains accessible.

Repeat this process for every workspace you need, including unfinished experiments and older work that contains useful decisions. Assign an owner to each verification rather than assuming another team member exported shared work.

Download and inspect the account archive

Create the account archive even after your workspaces appear locally. Open Settings → Account → Export data, then save the resulting download outside Conductor’s workspace directories. Complete and verify this export before November 20.

Keep another copy in your team’s approved backup location. Open the export locally with a suitable viewer, and check representative project records and conversations. Record the export date and any missing material.

Treat this archive as a backup to inspect, not an assumed import format for another coding tool. Reconstruct a working environment from verified code, separately saved files, configuration, dependencies, and credentials.

When Transfer to local is missing or fails, use the matching recovery route below. Recover pushed commits from the approved remote, or bundled commits from the verified mirror. Recover missing material from Cloud only if it remains accessible. Export the account archive separately, but do not treat it as proof that unfinished code is recoverable.

Record the app version, affected workspace, and exact error. Use the support contact in Conductor’s announcement before the deadline. Do not send credentials or sensitive conversation contents.

During the announced read-only period, old chats and data exports remain available. Do not make recovery depend on a new agent message, a workspace transfer, or a Cloud terminal still working after November 13.

Recover a working checkout from the backup

Recover committed history from the approved remote if you pushed it, or from restored.git if you made a bundle. Choose one route, then follow the shared file and deletion recovery steps below.

For pushed commits, open Bash in an approved local recovery directory. Enter the approved remote URL without embedded secrets. Use the branch name without refs/heads/ and the full commit ID from your inventory. Use your normal Git authentication and an unused recovered-worktree directory:

read -r -p "Approved remote URL (no embedded secrets): " RECOVERY_REMOTE &&
read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
mkdir recovered-worktree &&
(
  cd recovered-worktree &&
  git init &&
  git remote add origin "$RECOVERY_REMOTE" &&
  git fetch origin &&
  git switch --create "$RECOVERY_BRANCH" "$RECOVERY_COMMIT" &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

The fetch step retrieves remote history. git switch --create creates the intended local branch at the recorded commit, not the latest remote tip. Stop if authentication fails, the recorded commit is unavailable, or either comparison fails. Obtain the missing commit from a verified bundle or an accessible Cloud workspace; do not substitute a different commit.

For a bundle backup, open Bash in your local conductor-history-backup directory. Enter the branch name without refs/heads/ and the full commit ID from your saved inventory. Use an unused recovered-worktree directory:

read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
git clone --branch "$RECOVERY_BRANCH" restored.git recovered-worktree &&
(
  cd recovered-worktree &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

git clone --branch selects the checkout branch. git branch --show-current checks its name, and git rev-parse --verify HEAD checks its commit. The final status report appears only after both comparisons succeed. Stop on an error or mismatch.

After either route succeeds, work inside its new recovered-worktree checkout. Copy saved modified, added, and untracked files to their original relative paths. Restore required ignored files separately. Keep the original backup copies unchanged.

Use pre-transfer-status.txt and your presence notes to reconstruct deletions and renames. Remove each recorded deleted path only from the recovery checkout, after confirming it was absent from the final snapshot. For a rename, restore the saved new path and remove the old path only if the snapshot no longer contained it.

Run the inventory commands again from the recovery checkout’s root. Reconcile every changed path with the saved status and check file contents against the independent copies. This restores working-tree contents, not the original staging state. Review differences before staging or resuming agent work, and do not push to the backup mirror.

Use local Conductor as a temporary bridge

Keep local Conductor for continuity while you remove dependencies on its workspace interface. The announcement promises new models and critical bug fixes until early 2027, followed by a wind-down. That does not extend the November 20 Cloud deadline.

Validate the execution environment after transferring a workspace. Conductor’s Cloud workspace documentation describes a Linux sandbox connected to your Mac. A working Cloud build is therefore not proof that the same dependencies and commands will work locally.

Local execution also does not mean offline model inference. Conductor’s privacy documentation says local workspace model traffic goes to the configured model provider.

Plan for a different process lifetime. The Cloud FAQ says local workspace sessions end when you close Conductor or shut down your Mac. A transferred workspace is not a substitute for an always-running Cloud worker.

Use this transition period to make the repository usable without Conductor. Keep setup instructions, test commands, and task handoffs in reviewed project files. Check your model provider’s allowance or API bill separately from Conductor’s free-Pro policy.

Rebuild parallel work with Claude Code, Codex, or OpenCode

Start with the coding agent you already use, then restore parallel work through separate Git worktrees. A worktree is another checkout of the same repository, usually on a different branch.

This approach suits developers who can run their projects locally and review changes through Git. It recreates separate working directories, not Conductor’s shared Cloud service or its complete interface.

Choose the agent and verify authentication

Install and authenticate your chosen CLI outside Conductor before moving a task. The mixed-agent example below requires both Claude Code and Codex installed and authenticated. For a single-agent migration, run your chosen CLI in both worktrees instead.

Use Claude Code when you want to retain your Claude Code workflow. Run claude inside the project directory and follow its first-use authentication prompts.

Use Codex CLI when you want to retain your Codex workflow. Run codex inside the project directory. Its first-run flow offers ChatGPT sign-in or another available authentication method.

Use OpenCode when you already rely on its provider configuration or want that choice of providers. Run opencode, then use /connect and /models as described in its provider instructions.

Do not assume credentials configured only inside Conductor are available to a standalone CLI. Verify the active account, provider, and model before granting access to a real task.

For a separate pay-as-you-go API route, BetterToken publishes tool-specific Claude Code and Codex setup guides. Keep model-access configuration separate from workspace recovery. Use the Claude Code and Codex API first-test checklist before moving a production task.

Create two worktrees and check the complete workflow

Begin at the root of your verified local repository, using a known committed checkpoint. The following Bash example creates two branches from the current HEAD:

git worktree add -b migration/docs ../migration-docs HEAD &&
git worktree add -b migration/tests ../migration-tests HEAD &&
git worktree list

Git’s worktree reference documents branch creation with -b and inspection with list. Confirm that the output contains both new directories and their corresponding branches.

These are fresh checkouts of the committed state. They do not copy uncommitted files or Conductor chat state. Preserve pending recovery work before using this example.

Use unused branch and directory names. On a creation error, inspect the existing state before retrying. Do not add --force merely to get past an error.

The next two launch commands assume that both Claude Code and Codex are installed and authenticated. Open two terminal tabs, each initially at the original repository root. In the first tab, start Claude Code:

(cd ../migration-docs && claude)

In the second tab, start Codex:

(cd ../migration-tests && codex)

For a single-agent setup, use the same installed CLI command in both directories: claude, codex, or opencode. Avoid running two editing agents against the same working directory.

Start with this verification prompt in each session:

Use read-only tools to inspect this repository.
Report the current directory and Git branch.
Identify the documented setup command and one existing test command.
Cite the repository files that define those commands.
If a command is not documented, say so.
Do not edit files, install packages, commit, or push.

The expected result is two reports tied to different directories and branches. Each report should cite real repository files, not invent a generic test command. Keep normal approval controls enabled; a prompt is not a security boundary.

Once those checks pass, approve the required setup and run a small existing test in each worktree. Then assign independent tasks, such as a documentation correction and a separate test improvement. Review each resulting diff before committing or merging.

Use the exported conversations to write a short handoff for each task: its goal, constraints, completed changes, remaining work, and last test result. Review imported instructions and hooks before reuse; the agent configuration audit guide provides a useful checklist.

Do not confuse a new CLI session with restored conversation history. OpenAI’s import documentation lists Claude Code and Cursor as Codex CLI import sources. It does not establish that a Conductor account archive can be imported directly.

Separate worktrees also do not provide separate databases, service accounts, or development ports. Assign those resources deliberately before running parallel builds. Conductor itself distinguishes workspace isolation from a security boundary.

Track the provider allowance or API charges for each active session. For example, OpenAI’s authentication documentation distinguishes API-key billing from included ChatGPT plan credits. Adding terminal tabs does not create another subscription allowance.

Mark the migration complete only after the archive opens, required files and commits are accounted for, and a local task passes its checks. Keep unresolved workspaces on the migration list until their owner verifies them or explicitly records what could not be recovered.

Ready to optimize your LLM workflow?

Join thousands of developers building faster, smarter, and more cost-effective AI applications with BetterToken.

Get Started for Free