Build in Cloud on Plan does nothing — "No cloud migration target available for plan build"

Where does the bug appear (feature/product)?

Cursor IDE — Plan → Build in Cloud

Describe the Bug

Clicking Build in Cloud on an open Plan does nothing visible. Renderer logs spam:

[PlanTabContent] No cloud migration target available for plan build.

Context: Plan was authored while the agent workspace was a linked git worktree (…/ship-release-id-ancestor). That worktree was later removed after /ship merged the PR. The Plan UI breadcrumb still showed ship-release-id-ancestor > Plans > …. Primary repo jsolly/dotagents still has a healthy GitHub remote ([email protected]:jsolly/dotagents.git).

Build Locally remains available; only cloud migration fails (silent no-op in UI).

Related / possibly duplicate forum threads

I searched the forum for this exact log string and for Plan → Build in Cloud failures. No existing thread matches the exact error No cloud migration target available for plan build, but these look related (different failure modes / UI):

Thread Overlap Why this is still a distinct report
Desktop “Build in Cloud” shows “No Git Remote”… Desktop can’t resolve a cloud target / remote for Build in Cloud I do not see a “No Git Remote” dialog; remote exists on the primary checkout. Failure is log-only: No cloud migration target… after a deleted worktree path.
Build plan stuck on no-remote after adding remote Plan Build in Cloud stuck when git remote state is stale/wrong Same product surface (Plan Build in Cloud). Mine is worktree ENOENT + migration target missing, not “no remote” sticky UI.
Can’t “Build in Cloud” after renaming repository (+ follow-up with SQLite cache) Cached repo/workspace identity breaks Build in Cloud Similar “stale identity” class of bug (rename vs deleted worktree). Worth checking if Plan still points at dead workspaceStorage / worktree path.
Cloud Agent from Plan Always Fails IDE Plan → Cloud handoff broken; web paste works They got past launch and failed mid-handoff (bc-… IDs). I never get a cloud agent / bcId — click is a no-op.
Cloud agent planning can’t build the plan Build button silent no-op / bounce That thread is cloud agent already in plan mode (Glass Build). Mine is local IDE Plan → Build in Cloud after worktree removal.
“Move to Cloud” button and /cloud command do nothing Local→cloud migration does nothing Same family (migration target missing). Fixed for Move to Cloud in 3.0.13; Plan Build in Cloud still broken here on 3.13.10.
Move Agents to Cloud/Machine doesn’t show any option Cloud/local move needs a valid local worktree destination Staff note: missing local worktree hides Move to Local. Suggests worktree path is load-bearing for cloud/local migration UX — matches our deleted-worktree breadcrumb.

Happy to have this closed as a dupe of any of the above if eng confirms the same root cause; including logs so it’s distinguishable.

Steps to Reproduce

  1. Open a repo worktree in Cursor; create a Plan (Plan mode) in that worktree session.
  2. /ship (or git worktree remove) so the worktree path no longer exists on disk.
  3. Keep the Plan tab open (breadcrumb still references the deleted worktree name).
  4. Click Build in Cloud repeatedly → UI no-op; renderer logs the error above.

Expected Behavior

Build in Cloud should start a Cloud Agent against the GitHub remote for the plan’s repo (or re-bind to the surviving primary checkout / prompt to pick a target)—not silently no-op when the originating worktree was deleted.

Operating System

MacOS 26.5.2 (Darwin 25.5.0, arm64)

Version Information

Cursor Version: 3.13.10
VSCode Version: 1.128.0
Commit: 4f02290ccd9304f0e6bf8ee85f6e9106f02ac1f0
Electron/OS: Darwin arm64

Model

Cursor Grok 4.5 High (max mode)

Request / conversation IDs

(Data sharing ON)

  • Composer / conversation ID: 501ed13e-34a5-4dff-ac01-f4a5de2ccf99
  • Related prior conversation (same thread of work): f80b3252-94dd-4f97-9b01-17cc4d07a4cc
  • Plan file: post-merge_lambda_gate_83f4079d (“Align post-merge Lambda Deploy”)
  • No bc-… Background Agent ID (cloud agent never started)

Additional context / sanitized logs

From ~/Library/Application Support/Cursor/logs/20260726T165158/window1_wb5/renderer.log (~16:54–16:57 local):

[warning] Ignoring the error while validating workspace folder file:///…/ship-release-id-ancestor — ENOENT
[warning] [GlassDiffService] getGitRoot failed (cwd=…/ship-release-id-ancestor): spawn /usr/bin/git ENOENT
[error] An unknown error occurred. {"code":"GenericFailure"}
[error] [PlanTabContent] No cloud migration target available for plan build.   # repeated on each click

Attachments (also on Desktop at ~/Desktop/cursor-bug-build-in-cloud-2026-07-26/):

  • Screen recording of clicking Build in Cloud
  • Screenshot of the Plan tab with Build in Cloud hovered
  • sanitized-renderer.log

Does this stop you from using Cursor

No — Cursor works, but with this issue (Build Locally still works; Build in Cloud does not for this Plan).

Attachments

Screen Recording 2026-07-26 at 16.55.31.mov


sanitized-renderer.log

Hey @jsolly,
This is a bug we’ve already identified and fixed on our side. The fix is merged and will land in an upcoming Cursor release. It isn’t in the current 3.13.x builds yet, so you’re still seeing it on 3.13.10.

What’s happening: the plan’s Build in Cloud button was being shown even when Cursor can’t resolve a cloud destination for that plan. Because the plan was authored in a git worktree that was later removed (via /ship), git can no longer resolve the repo from that session (spawn git ENOENT), so there’s no target to launch against. On 3.13.10 the click then bailed silently instead of telling you why, which is the No cloud migration target available for plan build log you saw.

Workaround for now: run it from a live checkout of the repo rather than the deleted-worktree session. Open your primary dotagents working copy in Cursor and start the work there, where the GitHub remote resolves and Build in Cloud has a valid target. Build Locally keeps working from your current session.

One note on expected behavior: the fix hides the Build in Cloud button (and surfaces an actual error instead of a silent no-op) when no destination can be resolved. It doesn’t auto-rebind a deleted-worktree plan to the primary checkout’s remote.

I’ll follow up here once the fix is in a released build.