All docs

Worktrees and pull requests

Each thread can get its own git worktree, so agents work on an isolated branch and never touch your checkout. Setup is fail-closed: if the worktree cannot be created, the thread errors instead of silently running in your working copy.

Each thread can get its own git worktree, so agents work on an isolated branch and never touch your checkout. Setup is fail-closed: if the worktree cannot be created, the thread errors instead of silently running in your working copy. The worktree diff is a full-height Git pane in the thread center, Environment's Open Git, the next-action Commit, and /review all open it there, not as a card in the right-hand panel. The Environment tab still runs git pull --ff-only, starts the project dev server, and holds Fork and Handoff.

In that pane the Changes list has a checkbox per file and a tri-state header checkbox: a commit or a merge stages only the files you ticked, and the button names the count. Everything is checked by default, so leaving it alone commits the lot as before. Clicking a line number in the diff opens an inline comment box; sending it posts that comment to the agent as a follow-up prompt with the file, the line number and the quoted diff line attached, so a review note goes straight back into the run.

Each hunk has its own stage checkbox and a discard button, so you can commit part of a file or throw away one hunk and keep the rest. A changed image (PNG, JPEG, GIF, WebP, BMP) shows its before and after side by side instead of a text diff, at Fit, 100% or 200%.

A worktree thread can start on a chosen local base branch, shown in the header and the Git pane. Change the base before the first PR and Solenta rebases this thread's commits onto the new branch; a dirty tree or a rebase conflict is refused and the recorded base stays put. After the first PR the control hides, because the pull request already names the target.

The header carries one next-action button that names the next git step (commit, push, open a PR, watch checks, or merge) instead of a row of always-visible controls. Create PR works on an unpublished worktree without a prior Push. Create PR opens a PR workspace dialog: title, an editable body, a draft toggle and a markdown preview. The body starts from the repo's PULL_REQUEST_TEMPLATE in the root, docs/ or .github/, including files in a PULL_REQUEST_TEMPLATE/ folder. After the PR is open you can view it, edit the body, comment, mark it ready, close it or merge it from the same pane, without a trip to the browser. Its Code tab reviews the PR's files in the app, across all commits or one at a time. Mark files viewed; a file that changes in a later push flips to Changed. A thread can link several PRs, including ones in other repos, and a stacked chain offers Rebase stack and Merge stack. File paths in the transcript open the file in that worktree. Create PR refuses a diff larger than the configured PR size cap (default 400 changed lines) before anything is pushed. The header then offers to split the branch into a stack of smaller PRs, or to create this one anyway. Empty the cap in Settings to disable it.

Claude shell-command permission cards allow editing before approval. Codex command cards are read-only; see Codex sessions for their approval controls.

Answer permission and plan cards from the keyboard, like the CLIs: y accepts (or approves the plan), n denies (or keeps planning), and a always allows for the rest of the session. A pending permission outranks typing: the keys work even while the composer has focus, and are not typed into it. The card's own fields (the command, the rule, plan notes) keep their keys, and a card the guardrail flagged as risky never takes keys from the composer. Always-allow on a shell command is a prefix rule such as npm test:*, not all of Bash; edit it, or allow the whole tool, under Always-allow options.

PR state is live: checks show as badges on the thread card, and merging is a button, not a terminal command. Worktree merge and delete are guarded, so you cannot drop unmerged work by accident. Automatic checkpoints are committed as the agent works, and you can restore to any checkpoint from the Environment tab. Restore rolls the transcript back with the files, not only the tree. The Git pane can also open a per-turn diff: what changed between two checkpoints, unified or split, with a chip per file, instead of the whole branch since the base. In the checkpoint list, tick any two checkpoints to compare them, or use Fork on one to start a new thread with that checkpoint's files and conversation.

Settings, Git has two opt-in merge settings. Review new PRs with a different provider has a worker on another installed provider review each PR a thread opens and send real bugs back to the author thread. Strip agent Co-authored-by lines from squash merges drops AI agent trailers and keeps human co-authors. A thread whose PR merged offers Open revert PR.

GitLab projects get the same flow for merge requests through the glab CLI: list, check out, create, squash merge, and CI badges from the head pipeline.

Work can also start from an issue: paste a GitHub, GitLab or Linear issue reference and Solenta pulls the title and body in as the thread's first prompt. Linear needs an API key in Settings (Git) or LINEAR_API_KEY in the environment.

When several worktrees run in parallel, conflict forecast compares what they are touching and warns that two branches are heading for the same lines while both are still cheap to redirect, rather than at the merge, when one of them has to be redone. Hover the pill to see the other thread and the colliding files.

Finished worktrees are cleaned up rather than accumulating: worktree GC gives each project a retention setting (a default applies when the project has not set its own), batch cleanup, and a visible disk-usage figure so you can see what the branches are costing you.

Worktree location in Settings, Threads moves new worktrees to another absolute folder; existing threads stay where they are. Solenta keeps two idle worktrees per project ready, so a new worktree thread starts without waiting on a full checkout. A new worktree gets copies of gitignored files listed in a checked-in .worktreeinclude (gitignore-style patterns), or the root .env* files when there is none. Existing files are never overwritten. If a thread's worktree folder was deleted, the next run restores it from the thread's preserved branch, so earlier commits are not lost.

Environment variables in Edit Project takes one KEY=value per line (# comments allowed). They apply to agent runs on every provider, workflow phase agents, the thread terminal, verify, setup and quick-action commands, and dev servers, locally and over SSH.

Other folders in Edit Project adds up to eight more folders next to the project's repo, one path per line (local projects only). The repo still owns git, worktrees, memory and skills. Agents can read and search the other folders, and a +N folders badge marks the project. On Claude, an edit in one of them asks first, and Allow writes to <folder> on the card grants that folder for the thread. Other providers can read them but not write there, and shell commands are not gated.

Coming from Vibe Kanban: Settings → Your data reads the local VK database (db.v2.sqlite in ~/Library/Application Support/ai.bloop.vibe-kanban on macOS) and turns cards into threads, mapping leftover worktrees when they still exist. The same section exports a JSON dump of your Solenta projects, threads, and messages. Nothing is locked in.

Development lanes and previews

For a local project, Environment's Lanes section lets a thread Claim lane. Each lane has a number, branch, working path and assigned PORT. Preview temporarily mirrors the selected lane into the project checkout; Restore returns the checkout afterward. This changes the checkout, so it is guarded against overwriting dirty work.

Spotlight is a per-project opt-in in Settings, Git. It does not merge or publish a lane. Recycle wedged reclaims eligible stale lanes; live runs and previews stay protected. Claimed lanes keep their heartbeat even when you switch away from Git or to another local project.

For the manual Git commands and a complete thread-per-task workflow, read How to run AI coding agents in parallel.