Repository navigation
feat(cloud): fork a cloud session directly into a new cloud session - #5909
Merged
Merged
Conversation
…ud session Extract the pure decision logic that turns a source session's runtime configuration into a clone-style prepareSession request: repository and model/mode inheritance, per-platform mapping, and rejection reasons with user-facing messages. The orchestrator guards organization boundaries and drives invalidation, navigation, and error reporting.
Adds the web UI for the cloud-to-cloud fork that previously only worked via CLI/VS Code round-trips. The sessions listing, session actions dialog, and read-only session continuation panel now offer 'Fork to a new Cloud Agent session', which clones the source session and navigates to the new session.
Non-cloud (CLI, Agent Manager, Gastown) rows cannot be cloned into a new cloud session: they have no cloud runtime configuration to inherit. Hide the new fork action unless the source row has a cloud_agent_session_id, keeping editor/CLI fork options intact.
- Forward runtime agents alongside a custom agent mode so profile-defined custom modes stay forkable (prepare requires the destination to carry the matching runtimeAgents). - Drop malformed runtime variants and validate repository fields instead of letting the fork fail at the zod boundary; fall back to the runtime git URL when githubRepo is absent, and infer the platform when runtime metadata omits it. - Reuse one operationKey per (context, session) after an ambiguous failure so a retry replays the settled create instead of minting a duplicate session; rotate the key once the fork settles. - Default SessionContinuationPanel.canForkToCloud to false so future callers must opt in, and only surface the new-session fork for rows that carry a cloud_agent_session_id. - Toast a generic message for unexpected failures instead of leaking internal zod/worker error text.
Custom agent lists read from runtime state are unconstrained while the prepare schema bounds each agent (slug/name/model/variant length and charset, 20 agents max). Prune invalid agents, cap the list at 20, and only forward variants alongside their model so a pathological session cannot reject the whole fork at the zod boundary.
maphew
marked this pull request as ready for review
September 6, 2026 06:16
Contributor
Code Review SummaryStatus: No Issues Found | Recommendation: Merge The continuation-panel cloud fork flagged previously was removed because it was unreachable, and no new issues were found in the incremental changes. Files Reviewed (2 files)
Previous Review Summaries (2 snapshots, latest commit db3dda6)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit db3dda6)Status: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)CRITICAL
Files Reviewed (6 files)
Fix these issues in Kilo Cloud Previous review (commit 844cf4a)Status: No Issues Found | Recommendation: Merge Files Reviewed (8 files)
Reviewed by deepseek-v4.1-flash · Input: 0 · Output: 0 · Cached: 0 Review guidance: REVIEW.md from base branch |
Co-authored-by: kiloconnect[bot] <240665456+kiloconnect[bot]@users.noreply.github.com>
Co-authored-by: kiloconnect[bot] <240665456+kiloconnect[bot]@users.noreply.github.com>
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Reviewed against the codebase. The split into a pure derivation module + tested orchestration + thin hook is good, and the derivation details line up with the prepareSession clone schema (mode slug, variant charset/max length, runtime-agent slug/name/model limits and the 20-agent cap, exactly-one-repository rule). Org-context matching, Bitbucket/unknown-platform rejection, and the GitHub/GitLab URL fallbacks all look correct.
Requesting changes for two reachability problems that make the new UI either unreachable or misleading, plus warnings noted inline.
Critical
SessionContinuationPanel'scanForkToCloudis effectively alwaysfalse: read-only resolution implies there is nocloud_agent_session_id, so the new button in that panel never renders.SessionActionsDialogoffers the cloud fork for CLI-only sessions, which contradicts the PR description; it always fails withThis session has no saved Cloud Agent configuration to copy.
Warnings
- The fork does not inherit the source session's profile, env vars/secrets, skills, or branch - it silently drops them.
- The
operationKeycomment doesn't match the code (rotates only on success), and the key only lives in memory, so it doesn't survive a reload after an ambiguous failure. MODE_SLUG_PATTERNomits the prepare schema'smax(50).- Every thrown error becomes a retry-inviting generic toast, including non-retryable
NOT_FOUND/FORBIDDEN.
Details are in the inline comments. Happy to re-review once these are addressed.
maphew
commented
Sep 16, 2026
maphew
left a comment
maphew
left a comment
Contributor
Author
There was a problem hiding this comment.
Addressed all 6 review threads in db3dda6: eligibility gating for both fork surfaces, profile/branch scope documented, operation-key comment corrected, mode 50-char cap enforced with test, NOT_FOUND/FORBIDDEN mapped to terminal messages. Thread replies posted inline.
eshurakov
approved these changes
Sep 17, 2026
This was referenced Sep 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #5999.
Cloud sessions can currently be forked to VS Code Kilo or the Kilo Code CLI, but not directly into another cloud session. This PR adds a cloud-to-cloud fork from the web session surfaces so users no longer need to round-trip through CLI/VS Code.
The fork reuses the existing clone path that mobile's "Continue in new session" already uses (
prepareSessionclone variant): the source transcript is cloned into a new Cloud Agent session that inherits the source session's repository, model, mode, and custom agents, then the user lands in the new session.What changed
cloud-session-fork.ts) with tests: turns a source session's runtime config into a cloneprepareSessionrequest, maps GitHub/GitLab repositories (with git-URL fallbacks and platform inference), forwards custom agent lists for profile-defined modes, and returns typed rejection reasons (non-cloud sessions, missing config, Bitbucket/unknown platforms, org mismatches) with user-facing messages.useCloudSessionForkhook: loads runtime state, runs the clone with an idempotency key that survives ambiguous failures, invalidates session queries, navigates to the new session, and toasts failures.cloud_agent_session_id(true Cloud Agent sessions).Validation
tsgo --noEmit, oxfmt, and oxlint clean for all changed files.operationKeyreuse across ambiguous failures, permissivecanForkToClouddefault, runtime-agent schema pruning, and raw server-error leakage.Follow-ups (not in scope)