Skip to main content
A workspace is the directory where a task operates; a session records the conversation and tool activity. Check the path and branch before sending a task, and state which changes you authorize.

​
Start a session

1

Choose a workspace

Open the target repository or directory and confirm the displayed path. Git features require Git installed on your system.
2

Create a session

Choose a model and describe the expected result, prohibited operations, and verification. Keep each session focused on one clear objective.
3

Review results

Inspect tool activity, file diffs, and test results before deciding whether to commit, publish, or keep changes.
Workspace selector and session list

​
Separate concurrent changes with worktrees

The built-in worktree integration can create a separate Git worktree and branch for a task, rather than writing directly in the main checkout.
  1. Explicitly request that the task run in a worktree.
  2. Review diffs, verification results, and uncommitted changes in the isolated session.
  3. To bring the work back to the local repository, explicitly approve checkout and name the target branch.
A completed task or merged PR is not checkout authorization. Checkout removes the isolated worktree. Commit work you need to preserve, and choose to carry staged changes when needed. Do not assume unstaged or untracked files will be brought back automatically.
Use session archives to organize history; archiving does not save every uncommitted worktree change.

​
Safety boundaries

  • A workspace path is not a permission sandbox; actual tool permissions and approvals apply.
  • Git worktrees separate branches and files, not processes, networks, or credentials.
  • Profiles separate configuration and plugin environments, not all session data.
  • Keep secrets out of prompts, source, and public logs; review generated commands as code.
Use real operating system isolation for untrusted repositories. See Data, privacy, and security for storage and backup scope.