Move channels between local and hosted with the same workspace #181

Move a channel between this host and a team-deployed hosted cell while keeping its workspace, repository files and lane paths on the same machine. The first implementation is a roundtrip for one idle owned channel through the CLI and a basic channel context menu, merged in #194. Work added while hosted must come back with it.

Status — initial slice merged October 7

PR #194 merged as 11e4f405 at 14:10:00 UTC, from reviewed head 84bee42ef3944da43e3ebe9f7835340a5d765cd5. PR CI and post-merge main CI passed; bun types and bun run ci passed. This issue remains open for the deferred checklist below.

Focused real roundtrip evidence: local M1 → outbound CLI → hosted M2 using a local shell → actual Move to: → This host menu → matching returned history/info/usage and local M3 continuation. The menu offered the cloud service again. Validation used the dedicated pilot service and a shared-app UI check automated by Codex in Chrome; it does not claim a separate signed Ace desktop acceptance pass. Existing non-pilot services were unchanged.

The shipped limit is pi schema 1 and 32 MiB, on the same workspace/lane paths, with no automatic backups. A first post-deploy 404 failed safely and preserved the local store; its cause was not established. Busy/unfinished-work refusal and exclusive-cutover guards were source-reviewed. The focused live roundtrip does not certify the broader refusal/interruption/retry matrix retained below.

Initial CLI and context-menu slice — delivered

The user explicitly chose this narrow first implementation with no automatic backups. General backup/restore #178 was not a prerequisite. The integrated PR #194 used Refs #181; its merge completes this slice while this issue stays open for the deferred work below.

• Provide explicit CLI operations to move one idle local channel to a selected hosted service and move that hosted channel back to this host. Keep its stable channel id; no replacement channel or history reset.
• Add a Move to: section to the channel context menu for idle owned channels, listing applicable candidates: known supported hosted service destinations or the same local workspace when returning from hosted. Selecting a candidate uses the same move operation and retains channel identity/state. The initial menu does not include a setup wizard or moves to another workspace.
• Carry the complete durable pi state in both directions: chats/children, messages, tool calls/results, metadata, usage, owner, sharing settings and relevant channel/model configuration. Returning local includes work added or changed while hosted, rather than reopening a stale pre-move local snapshot.
• Keep the same workspace, project checkout, dirty/untracked work, lanes and absolute lane paths. Tools continue on this machine when the channel is hosted. This slice transfers channel state and execution of the channel loop, not project files or tool execution to another machine.
• Reject a busy channel, including active child-chat work, before moving it. Admit no new work through the cutover that could race the idle-state check. Refusal leaves the existing channel usable in its current location.
• Make the cutover explicit and exclusive: only one local worker or hosted cell may own active execution of the channel. Verify the imported destination state before switching authoritative routing, and do not report success until the same channel can be opened at its new location. The initial path still requires at most one active owner; the broader interruption/retry recovery matrix is deferred below.
• Use the small, bounded portable representation pinned to pi schema 1, with a 32 MiB UTF-8 limit and SHA-256 digest. Reject unsupported versions, over-limit data or conflicting destination state before a successful cutover. Keep pi-durable authoritative; do not add another durable messages/runs/chats store or a general migration framework for this slice.
• Run a focused real local → deployed hosted → local roundtrip, adding a real model/tool turn while hosted. Verify stable identity, retained original and hosted-added state, unchanged local lane files/paths and the old cloud copy refusing ordinary requests after return. Exercise the basic Move to: menu, selected-chat reconnection and applicable return/cloud destinations. Independently review busy/unfinished-work refusal and owner/admission/exclusive-cutover guards; a complete runtime refusal matrix remains deferred. Keep validation proportional to this shipped path; no automatic backup or broad failure-injection suite is required for the initial change.
• Document the CLI and basic Move to: menu, idle/same-workspace/same-version/size limits, absence of automatic backups and any manual recovery limitations. Be explicit about unsupported states rather than silently dropping durable state.

Keep packages/channel runtime-neutral, use the shared protocol types, and preserve the tailnet trust model. No backups are automatically created by this initial path; the user accepts that omission. Existing channel data must still be transferred intact, without a store reset to make the move work.

Deferred work retained here

• Backup and restore — Back up and restore hosted channels #178. Keep the supported hosted recovery path, exercised restoration, retention and any later automatic pre-move backup policy in that issue. The initial CLI/menu path does not depend on it.
• Active/unfinished-run movement on the same workspace. Move channels with active or queued runs and child-chat work, preserving resumability and accounting for in-flight side effects without blind replay. Kill is not a migration operation. This same-workspace scope remains here; Move a channel to another host so work can continue on that machine #49 separately owns moving execution and files to another host.
• Interruption and retry recovery. Harden crashes, lost replies, network loss and repeated commands during export/import/cutover; provide clear resume/rollback paths, preserve usable source data on failure and prove that retries cannot create two active owners. Keep the initial ownership guarantee while expanding this recovery matrix.
• Larger channels and cross-version portability. Extend the bounded same-version representation only when needed, with suitable transfer limits/streaming and versioned pi/state compatibility. Retain all durable state and exercise migrations against existing data rather than resetting it.
• Broader app discovery, setup and preferences. Extend beyond the initial Move to: menu over known supported destinations with service discovery, setup/configuration and preferences. Reuse the service setup/workspace-status work in Create hosted channels and show workspace status in the app #177 and preserve project-first behavior. The basic context-menu movement is part of the initial slice above, not deferred here.

The original scope also required child-chat state, dirty/untracked lane work, interrupted-transfer acceptance, source preservation and recovery. Those requirements are retained above: ordinary durable state and local lane preservation belong to the first slice; live-run movement, comprehensive failure recovery and broader qualification remain unchecked followups.

Tracked by #13. Pilot #176 holds deployed/runtime qualification. Hosted lifecycle/discovery #179, hosted messaging #180, hostless browser access #182, and execution-host handoff #49 remain separate scopes. Keep this issue open after the initial CLI/menu PR merges until its remaining work is completed or explicitly assigned to another tracker issue.