Operate the system
Use worktrees and multi-root workspaces safely
Isolation and broader context solve opposite problems. A worktree protects the main working state; additional roots let a task read or change related repositories. FireCursor makes both deliberate launch choices.
Quick answer
The shortest useful version.
Use a worktree for risky or parallel changes. Add extra roots only when the task genuinely spans them, verify every path, and keep the smallest possible write scope.
Step by step
Do this with confidence.
- 01
Decide between isolation and expansion
Choose an isolated worktree when the task should not disturb the current checkout. Choose multi-root only for an actual cross-repository dependency.
- 02
Verify every root
Read the resolved project names and paths. FireCursor supports up to eight trusted workspace roots; capacity is not a reason to add them.
- 03
State write boundaries
Tell the agent which roots are read-only, which files may change, and how cross-project verification works.
- 04
Review each repository
Inspect status and diffs independently, then run the integration check that proves the combined result.
Worktrees are a strong default for exploration
An isolated worktree reduces interference with existing changes and makes abandonment cleaner. It does not remove the need to review, test, and understand the branch before integration.
Multi-root workspaces should be rarer because every added root expands the context and potential mutation surface.
Boundary checklist
- All paths are expected and trusted
- Branch ownership is clear
- Read-only roots are named
- Generated files stay in their owning project
- Integration verification crosses the same boundaries as the change