Moving off Conductor

The dates, and what to export

If you only use local workspaces, the app isn’t urgent, and Conductor says it hopes to have something new by then. Your Claude Code chats have a shorter clock: see work in progress. If you use Cloud, do these before 13 November:

1. Push your branches. Commit and push anything you want to keep from a cloud workspace while its agent can still take messages.
2. Transfer what you’re still working on. Right-click a cloud workspace and choose Transfer to local to move it and its chats to your Mac.
3. Export everything else. Settings → Account → Export data downloads an archive of your Conductor data. Keep it private.
4. Write down your Cloud Computer. Copy its setup scripts, installed software and the names of its environment variables and secrets. The announcement doesn’t say whether the export includes them.
5. Find what calls Conductor. Note every script, bot or service that uses a routine’s webhook URL or the Conductor API, so you can point it somewhere else.
6. Clean up access last. Once your work is out, rotate any API keys, tokens and passwords you entered in Cloud. Then remove the Conductor GitHub App: on GitHub, Settings → Applications for your account, or Settings → GitHub Apps for an organization.

Dates and the first three steps from Conductor’s announcement.

Work in progress

A local Conductor workspace is an ordinary git worktree, so you can carry on in it without an import. Conductor keeps them in ~/conductor/workspaces/<repo>/<workspace>. Older versions used <repo>/.conductor/<workspace>. git worktree list in your repo shows where each one is, and a workspace you moved with Transfer to local should be under ~/conductor/ too.

Don’t archive it in Conductor yet. The migration guides from Paradev and Orca both say archiving deletes the folder, and uncommitted work exists nowhere else. Quit Conductor while you work in it, and keep ~/conductor/ until you’re done.

Bring it in:

1. Pick the repo. In New task, choose the project your workspaces came from, or add it. When the prompt box is empty and wisp finds Conductor’s worktrees of that repo, it shows one line, such as 3 worktrees from Conductor.
2. Press Bring in. Each worktree becomes a task right where it is, on its own branch, with its uncommitted changes as they were. wisp runs no setup and writes nothing in the folder. Not now stops offering those folders.
3. Send a message. If wisp finds a Claude chat for that folder in ~/.claude, your message resumes the newest one on Claude Code. If not, it starts a new chat on your default harness, and the task’s first report says which happened.
4. Ship from the task. Ship it and Merge work as usual. Archive, delete and merge all leave the folder and its branch in place, because they’re Conductor’s to remove.

For a folder that isn’t offered, open it in place:

1. Open the folder with worktrees off. In New task, choose Other folder…, add the workspace folder’s path and switch Worktree to In place. Or from a terminal:

   wisp "Finish the retry logic" --no-worktree \
     --cwd ~/conductor/workspaces/app/lisbon

   The agent starts on that branch with your uncommitted changes and untracked files. With worktrees on, wisp would start a new branch from origin/main and leave that work behind. In place stays set for new tasks, so switch it back afterwards.
2. Ship from the task. Ship it needs a task with its own worktree, so ask the agent to commit, push and open the PR, or do it in the side panel’s Shell. Changes lists only what the task edits, so use git diff in Shell to see the work you came in with. Archiving or deleting the task leaves the folder alone.

For a chat Bring in doesn’t resume, or after opening a folder in place, reopen it yourself. A task can’t show a Conductor chat’s messages, but the agents keep their own copies: Conductor’s docs say Claude Code and Codex store their files in ~/.claude and ~/.codex. Claude Code keeps each chat under ~/.claude/projects by folder, so you can reopen it from the same path, in wisp’s Shell or any terminal:

cd ~/conductor/workspaces/app/lisbon
claude --resume

Claude Code’s picker leaves out chats started through its Agent SDK or claude -p. If yours isn’t listed, its session ID is the file name in ~/.claude/projects/<folder>/ (the folder’s path with each symbol as -), and claude --resume <id> opens it. For Codex, run codex resume in the folder.

Claude Code deletes transcripts after 30 days by default. To keep yours for longer, raise cleanupPeriodDays in ~/.claude/settings.json now, since a deleted chat can’t be resumed:

{
  "cleanupPeriodDays": 365
}

Conductor, mapped onto wisp

Both put each agent in its own worktree and branch and end in a pull request. wisp runs the agent CLIs you install (Claude Code, Codex, Cursor, opencode, Antigravity, Grok, Copilot), signed in with your own plans, on your computer, your other machines, or a wisp on a server.

What you gain

• Windows and Linux. Conductor is a Mac app. wisp runs on macOS, Linux and Windows, as a download or with npx wisp-agents.
• Other machines. Run on sends a task to any computer you can reach over SSH or added to the grid, with its worktrees, diffs and Ship it over there.
• Local tasks on any phone. Remote control needs Conductor’s iOS app. A computer you add to the grid opens in a browser, Android included.
• Open source. wisp is MIT, so no one can switch off the copy you run.

Still choosing? Conductor alternatives sets wisp next to six other apps, from their own docs, and says where each is better.

What doesn’t carry over

• scripts.archive. wisp has no step that runs when a task is archived. If yours removes something outside the worktree, run that cleanup yourself or ask the agent to do it before you archive.
• Multiplayer. Each person has their own wisp, so there are no shared workspaces, shared chats or Reassign to. Share work through branches and PRs. You can share crew members.
• The Cloud Computer. There’s no organization-wide environment with builds. Each person’s box starts from the same image, and what the agent installs in its home folder stays there. Repeatable steps belong in "setup".
• Several actions. wisp runs one command per repo, not a menu of named actions: of several, the one with default = true, or else the first. There’s no run_mode or Spotlight testing.
• Your chats. Bring in resumes a workspace’s newest Claude chat, but a task never shows a Conductor chat’s earlier messages. For the rest, keep the export, reopen Claude Code and Codex chats from the same folder, or restart work from the branch.
• Environment variables in settings. wisp has no key for them. Keep values in an ignored .env file, which is copied into the worktree for your app to read, not set for the agent. wisp also skips ! lines in .worktreeinclude, so check any file that uses them.
• SSH and file sync. A wisp Cloud box has no SSH or sync to your computer. Use the side panel’s Shell, or run tasks on a machine of your own.
• A native iPhone app. On an iPhone, wisp Cloud is a Home Screen app with alerts through ntfy. Android has a prototype app you build from the repo, and any phone browser works.

Set up a repo the Conductor way

1. Start wisp in the repo with npx wisp-agents. It runs on macOS, Linux and Windows. Sign in to the agent CLIs you want, and to the GitHub CLI (gh auth login) so Ship it can open PRs.
2. Keep your scripts. wisp reads .conductor/settings.toml or conductor.json in the repo as it is, so this works with no changes, and $CONDUCTOR_PORT is set:

   [scripts]
   setup = "pnpm install"
   
   [scripts.run.dev]
   command = "pnpm dev --port $CONDUCTOR_PORT"

   wisp doesn’t read .conductor/settings.local.toml, environment_variables or what’s kept only in Conductor’s app. If a script lives only in the app, copy it into .conductor/settings.toml or .wisp/worktree.json. If wisp can’t read a file for sure, it uses none of it, and the task and Run say why.
3. Bring your ignored files. Keep .worktreeinclude if you have one. If you set file_include_globs, move those patterns into a new .worktreeinclude. A list of your own replaces wisp’s default, so add .env and .env.* if you still want them.
4. Send a task off. In Plan and Edits, the first run in a repo lists the setup step and waits for Trust and start.
5. Open Preview in the side panel to run the app from that task’s worktree, then read the report and press Ship it (S).

Webhooks, schedules and the API

A routine’s webhook becomes a trigger. Turn on Settings → Automations → Webhook triggers, add a When a webhook is called trigger and copy its secret URL. The JSON body goes into the prompt where you write it, such as {{body.report}}:

curl -X POST https://you.grid.trywisp.dev/api/hooks/<token> \
  -H 'content-type: application/json' \
  -d '{"report": "Login fails with a 500 on Safari"}'

• Starts in Plan. Webhook tasks start read-only by default, because whoever calls the URL writes part of the prompt. Change the mode on the trigger if the caller is yours.
• Limits. At most one task per trigger every 30 seconds. You can sign calls with an HMAC secret, and Regenerate replaces the URL.
• Where the URL lives. On wisp Cloud or your own Grid it’s public, and a call wakes a sleeping box. On your own computer it’s local, so put a tunnel in front.

On your own computer, the HTTP API answers locally, for scripts there. On wisp Cloud or your own Grid, a script anywhere can call it with a wgk_… API key. Make one in Settings → Connect in your cloud wisp, or Settings → Cloud on a desktop signed in to that Grid. You see it once. Then send it as a bearer token to your wisp’s address:

curl https://you.grid.trywisp.dev/api/sessions \
  -H "Authorization: Bearer $WISP_KEY"

• What a key can do. Everything you can do in that wisp, running tasks included, and only there: not your computers, sandboxes or account. Keys have no scopes, so for a caller you trust less, use a webhook trigger.
• Revoking. Revoke stops the key, not what it already started. If a leaked key was used, treat the box as compromised.
• A sleeping box. A call with a key wakes it, so the first one can take a moment. A 503 with retry-after means try again.

A bot that polled a transcript can long-poll GET /api/sessions/:id/wait and read GET /api/sessions/:id/presentation, or wisp can POST to your own webhook when a task finishes or starts waiting.

A computer that stays on

• wisp Cloud. Your own wisp in a sandbox at grid.trywisp.dev, with Claude Code, Codex, Cursor and opencode installed. It’s free during the preview, runs on one small server and sleeps when idle, so it suits one person better than a team’s heavy builds.
• Your own Grid. The same thing on a Linux server you pick, with sign-in through GitHub, Google or OpenID Connect. This is the closest fit for a team, sized to your own builds.
• Machines. Run tasks on any computer you can reach over SSH, or add it to the grid.

On a wisp Cloud or Grid box, Preview gets an address of its own, so there’s no port to forward. For a task on another machine, the preview may not load from your computer, so open the app on that machine.

Who can switch it off

wisp is MIT and open source, and it runs the official agent CLIs on a computer you choose. No one can switch off the copy you’re running or your own Grid, and if the project stopped, you could keep both going. wisp Cloud is different: it’s a hosted preview, so plan on the Grid if you need a server that’s yours. The agent CLIs and their plans still belong to their vendors.