Cloud start: the folder-grant wait is bounded and waits for the sent folder's grant

Merged
TE
1d ago
+148-18

Fix-forward of a review follow-up on #34427, which made a Cloud send wait for the folder grant from picking Cloud. That is part of Leo's Cloud refusal ask: "what happened here on this build?"

The wait had no time limit and waited on the last Cloud pick's grant, whichever folder that was. So a workspace.useFolder that never answered kept the composer locked forever.

  • cloudFolderGrants (cloudRun.ts) keeps grants by folder, spelled the way cloudStartFolder spells them. A Cloud start waits only for the grant of the folder it sends.
  • The wait stops at CLOUD_FOLDER_GRANT_WAIT_MS (3 s), and then the start is sent anyway. If the folder still isn't granted, the host's worded "pick the folder" refusal (#34406) covers it, and the prompt stays in the composer.
  • Timer: one setTimeout per waiting send. It is cleared when the grant settles, and it ends by itself at 3 s. A grant leaves the map once it settles.
  • grantedCloudStart is the pane's Cloud start, and App.tsx uses it as-is. New tests in cloudRun.test.ts drive that wiring: the start is held until the grant settles, it goes after the time limit when the grant never answers, and it waits only for its own folder's grant. A source check ties App.tsx to the helper.

Risk: small and contained in the Cloud first-send path.

Agent session: agent session

🤖 Generated with Claude Code


Autofix with [code]smith
Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.


Summary by cubic

Bounds the Cloud send's folder-grant wait so a grant that never answers can no longer hold the composer. A Cloud start now waits only for the grant of the folder it sends, and at most 3 seconds before sending anyway; the host's worded refusal still covers a folder that isn't granted.