Cloud start: the folder-grant wait is bounded and waits for the sent folder's grant
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 waycloudStartFolderspells 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
setTimeoutper 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. grantedCloudStartis 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](https://pr-comments-assets.blacksmith.sh/codesmith/autofix-with-codesmith-dark-3x.png)
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.