feat(code): import claude code sessions

[adboio]

🚨 feel free to pull this for testing downstack, but this is not the final UX! PR to be updated soon

Problem

Changes

How did you test this?

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

[adboio]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat(code): import claude code sessions #2873 👈 (View in Graphite)
• feat(workspace-server): import & store Claude Code CLI sessions #2877
• feat(agent): replay imported Claude Code CLI transcripts #2876
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit c316286.}

[greptile-apps]

Comments Outside Diff (2)

1. packages/workspace-server/src/services/agent/agent.ts, line 2534-2570 (link)

   Silent history loss when imported session fails to load

   When loadSession throws, agentSessionId stays undefined and the code falls through to start a fresh session. The import record in the DB is never rolled back, so the source session will continue to show as "imported" in the picker — but the task opened will have no history. The user has no indication that the replay failed; they'll see a blank task conversation and likely assume the import itself failed (it didn't) or that their history is missing permanently.

   Consider surfacing this failure as a task-level error event or a toast notification so users understand the session loaded without history, rather than discovering it silently.

2. packages/core/src/task-detail/taskCreationSaga.ts, line 859-868 (link)

   Fire-and-forget branch link can leave DB branch unset while workspace.linkedBranch appears linked

   linkImportedSessionBranch fires the linkTaskBranch mutation without awaiting, while the very next line sets workspace.linkedBranch synchronously. If the IPC call fails (and the caught warning is discarded), the persistent task record will have no branch linked — but the in-flight session object sees the branch as linked, so the branch-mismatch prompt won't surface during the current session lifetime. On the next reconnect, with no linked branch in the DB, the prompt will be absent again, silently never firing.

   Since branch linking is described as "best-effort", this may be acceptable, but it is worth documenting why the in-memory assignment still happens when the async call can silently fail.

_{Reviews (1): Last reviewed commit: "feat(code): import claude code sessions" | Re-trigger Greptile}

[greptile-apps]

recordCliImportInput accepts arbitrary strings for sourceSessionId and importedSessionId

Every other endpoint that uses these values as path segments (importCliSessionInput, deleteImportedCliSessionInput, deleteImportRecordInput) enforces z.string().uuid() with the comment "uuid keeps the value safe to use as a path segment." recordCliImportInput does not, even though the importedSessionId is recorded as a DB key and later passed to deleteImportedCliSessionInput / deleteImportRecordInput which do enforce UUID. The inconsistency means a caller that crafts a non-UUID importedSessionId in the record step could produce a row that is un-deletable via the delete endpoints (they'd reject the non-UUID value). In practice both values always come from the import endpoint's output, but adding .uuid() here makes the contract explicit and defends against future callers.

Suggested change

	export const recordCliImportInput = z.object({
	sourceSessionId: z.string(),
	importedSessionId: z.string(),
	repoPath: z.string(),
	taskId: z.string(),
	fingerprint: cliSessionFingerprintSchema,
	});
	export const recordCliImportInput = z.object({
	/** uuid keeps the value safe to use as a path segment. */
	sourceSessionId: z.string().uuid(),
	/** uuid keeps the value safe to use as a path segment. */
	importedSessionId: z.string().uuid(),
	repoPath: z.string(),
	taskId: z.string(),
	fingerprint: cliSessionFingerprintSchema,
	});