-
Notifications
You must be signed in to change notification settings - Fork 46
🤖 feat: implement fork for local workspaces #1721
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Add fork support for LocalRuntime (project-dir mode workspaces). For LocalRuntime, fork creates a new workspace entry pointing to the same project directory with copied chat history - enabling conversation branching without git worktree overhead. Changes: - LocalRuntime.forkWorkspace() now returns success with project path - Updated LocalRuntime class docs and tests - Added integration tests for local workspace fork
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5ee74a7137
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
The MuxMessage structure uses parts[] with type='text' objects, not a direct content property.
Added a stat check to verify the project directory exists before returning success from LocalRuntime.forkWorkspace(). This ensures users get a clear error rather than a broken workspace when the project directory is missing or inaccessible. Addresses review comment about defensive validation.
## Summary Fix local workspace fork creating corrupt worktree workspaces by persisting `runtimeConfig` in `config.addWorkspace()`, then simplify the codebase by removing redundant inline fallbacks. ## Background PR #1721 (commit 4238ff4) added fork support for local (project-dir) workspaces. The `LocalRuntime.forkWorkspace()` was correctly implemented to return the project path, and `workspaceService.fork()` correctly assembled the `FrontendWorkspaceMetadata` with `runtimeConfig: forkedRuntimeConfig`. However, when `config.addWorkspace()` stored the forked workspace entry, it **discarded the runtimeConfig field**: ```typescript const workspaceEntry: Workspace = { path: workspacePath, id: metadata.id, name: metadata.name, createdAt: metadata.createdAt, // runtimeConfig was missing! }; ``` On subsequent config loads, `getAllWorkspaceMetadata()` would see no `runtimeConfig` and apply `DEFAULT_RUNTIME_CONFIG` (type: "worktree" with srcBaseDir), causing the forked workspace to be treated as a worktree runtime. This created "corrupt worktree" errors because WorktreeRuntime operations would fail on directories that were never set up as git worktrees. ## Implementation ### Commit 1: Fix runtimeConfig persistence One-line fix: include `runtimeConfig: metadata.runtimeConfig` in the workspace entry when calling `addWorkspace()`. ### Commit 2: Remove redundant fallbacks The config layer already guarantees every `WorkspaceMetadata` has a `runtimeConfig` (via `DEFAULT_RUNTIME_CONFIG` applied in `getAllWorkspaceMetadata()`). This commit removes 13 inline `?? { type: "local", srcBaseDir }` fallbacks across 5 service files that were: - **Redundant**: The metadata type already includes runtimeConfig - **Inconsistent**: Inline fallbacks used `type: "local"` while the canonical default is `type: "worktree"` - **Bug-masking**: Silently substituting values instead of surfacing issues Files cleaned up: - `workspaceService.ts` (5 locations) - `agentSession.ts` (5 locations) - `aiService.ts`, `terminalService.ts`, `workspaceMcpOverridesService.ts` (1 each) ### Commit 3: Fix namedWorkspacePath persistence (Codex review feedback) `config.addWorkspace()` was hardcoding worktree-style paths (`~/.mux/src/...`) even for local workspaces. After app restart, this caused Open-in-Editor and path display to use the wrong directory. Fix: use `namedWorkspacePath` from the metadata if provided (which is computed runtime-aware by `Runtime.getWorkspacePath()`), falling back to worktree-style path only for legacy callers. ## Validation - Integration tests for fork persistence: - Creates local workspace → forks → verifies runtimeConfig survives reload - Verifies `namedWorkspacePath` is the project path (not `~/.mux/src/...`) after reload - `make typecheck` passes - `make static-check` passes - `TEST_INTEGRATION=1 bun x jest tests/ipc/forkWorkspace.test.ts` - all 9 tests pass --- _Generated with `mux` · Model: `anthropic:claude-sonnet-4-20250514`_ <!-- mux-attribution: model=anthropic:claude-sonnet-4-20250514 -->
Add fork support for LocalRuntime (project-dir mode workspaces).
Summary
For LocalRuntime, fork creates a new workspace entry pointing to the same project directory with copied chat history - enabling conversation branching without git worktree overhead.
Changes
LocalRuntime.forkWorkspace()now returns success with project path instead of an errortests/ipc/forkWorkspace.test.tsHow It Works
When forking a LocalRuntime workspace:
LocalRuntime.forkWorkspace()succeeds (returns project path)workspaceService.fork()copies chat history filesThis enables users to fork conversations to explore different directions without creating separate git worktrees.
Generated with
mux• Model:anthropic:claude-opus-4-5• Thinking:high• Cost:$1.55