Markdown edition

# Run two Claude Code Desktop tickets in separate projects

> Set up two local Claude Code Desktop worktree sessions for unrelated Git repositories, then verify each ticket's permissions, diff and tests independently.

By BIG CHANGE Editorial

Published: 2026-10-22T10:56:38.203Z
Updated: 2026-10-22T10:56:38.203Z
Canonical: https://bigchange.ai/blog/claude-desktop-two-independent-projects-guide

![Conceptual charcoal illustration of a developer viewing two separate generic coding panes on one wide desktop monitor.](https://bigchange.ai/api/media/file/claude-desktop-two-projects-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE.

Two unrelated coding tickets can run in separate Claude Code Desktop sessions, one tied to each Git repository. The useful result is two reviewable records: each ticket has its own checkout, diff, test result and commit or explicit hold. Desktop's split view helps you watch both sessions, but you still need to verify where each one can write and what else it can reach.

## The big change

- **What changed:** Claude Code Desktop supports local sessions in Git worktrees, a split view, an integrated terminal and a file-by-file Changes view. The pane and terminal layout used below requires Desktop v1.2581.0 or later.
- **Why it matters:** You can run two approved tickets in two independent repositories and assess each result against its own acceptance criteria, without making an integration branch between them.
- **What to watch:** Git worktrees separate checkouts, while permission approvals, hooks and external resources can still reach beyond a checkout. Check the effective rules and real service configuration before either ticket begins.

This is a documentation-based procedure. BIG CHANGE did not run either repository, Claude Desktop, tests or account usage. Bring two real repositories that you own or may change, two bounded approved tickets, each project's documented setup and test commands, and a reviewer for each result. Check that your source and secrets may be sent to the provider under your organization's rules. The [Claude Code Desktop manual](https://code.claude.com/docs/en/desktop) describes local sessions on macOS and Windows with an active eligible Pro, Max, Team or Enterprise account and Code-tab access. This guide uses **Local** sessions; cloud, SSH and WSL sessions have different file and terminal behavior.

If your tickets share a single Django repository and need an integration step, see our separate [same-repository worktree guide](https://bigchange.ai/blog/claude-code-django-parallel-worktrees-guide). The two projects here keep separate acceptance decisions.

## 1. Check the two projects and the shared limits

Open **About Claude** under **Claude** on macOS or **Help** on Windows. Confirm v1.2581.0 or later for the pane and integrated terminal used here. Check for updates in the same app menu if needed. Confirm Git is installed in your normal local terminal:

```shell
git --version
```

For each repository, write down its owner, root path, approved ticket, allowed files, acceptance check, documented setup and test commands, and branch and review policy. Keep any existing uncommitted, untracked or ignored material with its owner; do not clear it to make a worktree look clean.

Before starting a session, inspect the effective user, project, local and managed Claude settings available to you. Check **allow**, **ask** and **deny** rules, hooks, plugins, MCP servers and prior approvals for commands or external access relevant to each ticket. Desktop worktrees can read project configuration and hooks from the main checkout; a saved approval may also apply in later worktrees. The [permissions manual](https://code.claude.com/docs/en/permissions) explains why **Manual** does not promise a new prompt for every action. Resolve unclear authority with the repository owner without deleting rules or hooks used by others.

Compare the repositories' actual local settings for database URLs, ports, caches, queues, credentials, output folders and cloud targets. Different Git roots do not separate those resources. Use each project's approved disposable configuration where it exists. If an exclusive resource remains shared or its owner is unclear, run the affected tickets sequentially. Do not copy `.env` into a worktree simply to make it run. Keep production credentials and live data out of both tasks.

Agree with the owner on a usage allowance and a point at which to pause the two tickets. Click the **usage ring beside the model picker** and record its displayed plan usage with a UTC time before work starts. It reports usage shared across Claude Code surfaces, so it cannot price either ticket separately or enforce a project cap. If the available plan or allowance is unclear, settle that before dispatching work.

**Check:** You have two separate ticket briefs, known resource boundaries, an understood permission policy and a shared-usage baseline. If either project lacks one of these, hold that project's dispatch.

## 2. Start two worktree sessions, then verify their checkouts

In Desktop's **Code** tab, click **+ New**. Choose **Local**, select repository A's own project folder, choose **Manual** permission mode and an account-approved model. Turn on **Worktree** in the project-folder control **before the first message**. In an earlier Desktop layout, the worktree checkbox sits beside the branch name. Send a first message that only starts the session:

```prompt
Start in the selected worktree for this repository. Do not edit files, run commands or tests, contact external services, start servers, commit, or begin the ticket. Acknowledge that I will check the checkout and permissions first.
```

Repeat **+ New**, folder selection, **Manual**, **Worktree** and the same bounded first message for repository B. This startup creates each session's worktree; neither ticket is authorized yet. A worktree is a separate branch and checkout inside its own repository. If worktree creation fails, preserve the current files and arrange a repository-specific branch or checkout plan before work begins.

In each started session, enter `/permissions` and read its effective rules and source settings files. Compare them with the preflight record, including hooks and saved allow rules. Stop an affected session if a rule permits an unintended action; keep shared settings intact while the owner resolves it. Then open that session's **Terminal**. The [Desktop manual](https://code.claude.com/docs/en/desktop#run-commands-in-the-terminal) says it opens in the session's working directory. Run these read-only commands in **each terminal separately**:

```shell
git rev-parse --show-toplevel
git rev-parse --path-format=absolute --git-common-dir
git branch --show-current
git rev-parse HEAD
git worktree list
git status --short --untracked-files=all
```

Record the output for A and B. Compare each resolved worktree root, Git common directory, branch and base commit with its assigned repository and ticket. The two common directories must identify different repositories and the worktree paths must not overlap. Inspect status before the first edit; `git status` can reveal untracked files, while ignored outputs need a separate inventory under the project's policy. If a local terminal is unavailable, use your approved local shell at the exact verified worktree path and record that substitution. Do not guess Desktop's generated worktree name.

To see both sessions, hold **Option** on macOS or **Alt** on Windows while selecting the other session in the sidebar. You can also right-click its entry and choose **Open in → Split view**. Click the intended pane before every prompt: the last-clicked pane receives it. Split view does not join the repositories or their histories.

**Check:** Both sessions point to their intended, distinct Git repositories, and each permission record is acceptable. If a path, branch, base or rule differs, stop before sending a ticket and inspect the actual checkout and settings.

## 3. Dispatch each ticket within its own boundary

In A's focused pane, send only A's approved ticket, allowed file scope, acceptance check, documented commands and local resource restrictions. Ask Claude to stop for a conflict, missing dependency or unclear external effect. In B's pane, send B's separate brief. Use each repository's real stack and setup instructions; this guide cannot supply a universal install, build or test command.

Review proposed commands and edits under **Manual**, including actions covered by old allow rules or hooks. Before a server or test touches external state, read back its effective database, cache, output path, port and remote endpoint. Pause one ticket if both need an exclusive resource. Check the usage ring during work at the owner-agreed points and pause at the agreed stop point. The ring's change may include other Claude Code activity, so record the observation without attributing it to A or B.

Keep source, secrets and task context in their assigned sessions. Do not add repository B as another folder in A's session. If a session appears to have moved to the wrong checkout, stop it and inspect actual file and Git state before continuing. When a command's result is uncertain, check the affected files, status and service state before any retry.

**Check:** Each ongoing change stays within its ticket and approved runtime resources. An unclear write or shared service is a hold until its actual state is known.

## 4. Review and close the two results independently

For A, open Desktop's **Changes** view and read the entire file-by-file diff. In A's verified checkout, inspect actual source, untracked files and the output of:

```shell
git status --short --untracked-files=all
git diff --check
git diff --stat
git diff
```

Run A's documented ticket-specific tests and required checks in that same checkout using its approved local resources. Record each command, environment or tool version, exit status, meaningful output and the result against A's acceptance check. Repeat the whole review in B's checkout with B's commands and criteria. An optional `/code-review` can supply findings, but the responsible reviewer still decides whether each ticket meets its acceptance check. Recheck affected files and tests after a correction.

For an accepted ticket, stage **only** its reviewed paths. Replace the quoted placeholder below with one actual approved path, and repeat only for other reviewed files. Then inspect the complete staged diff and check it before a separate commit under that repository's policy:

```shell
git add -- "<actual-approved-path>"
git diff --cached --check
git diff --cached --stat
git diff --cached
```

After committing under the repository's policy, read back the result in that checkout:

```shell
git rev-parse HEAD
git branch --show-current
git status --short --untracked-files=all
```

If acceptance fails or a required check cannot run, leave that ticket's work in its own worktree with an explicit **HOLD** record naming the observed error and next authorized repair. A's decision does not determine B's. Any pull request follows the repository's normal review route and needs its own head, diff and CI check; pushing, merging and deployment require their usual owner decision.

Finish with **two records**, each naming its repository, ticket, worktree path, branch, base commit, full reviewed diff, tests, acceptance decision and commit hash or hold reason. Add a final UTC observation of the usage ring and any owner stop decision. Inventory untracked and ignored data before archiving either session or removing a worktree. The [Desktop manual](https://code.claude.com/docs/en/desktop#keep-uncommitted-changes-when-a-session-is-archived) warns that archiving can remove uncommitted or untracked worktree material, so preserve what the owner needs through that repository's normal route.

**Check:** The records describe two independent outcomes. No combined integration branch, cross-repository merge or unverified claim of saved time or cost is needed.

## Sources & further reading

- [Claude Code Desktop application](https://code.claude.com/docs/en/desktop): session startup, version and account checks, worktree control, split view, terminal, Changes view, shared usage ring and archive behavior. The controls may differ by installed version.
- [Claude Code worktrees](https://code.claude.com/docs/en/worktrees): what a worktree shares with its main checkout, including Git metadata, project configuration and permission behavior.
- [Claude Code permissions](https://code.claude.com/docs/en/permissions): effective allow, ask and deny rules, saved approvals, read-only exceptions and hooks.
- [Git worktree manual](https://git-scm.com/docs/git-worktree): linked checkouts and repository identity. Git alone cannot verify a project's external resource boundaries.

## Sources

- [Claude Code: Desktop application](https://code.claude.com/docs/en/desktop) — Checked 22 October 2026; no fixed publication date. Local session startup, account and version checks, worktree option, terminal, split view, Changes, shared usage ring and archive behavior.
- [Claude Code: Run parallel sessions with worktrees](https://code.claude.com/docs/en/worktrees) — Checked 22 October 2026. Worktree file and branch isolation plus main-checkout settings, hooks and permission sharing; external resources require separate checks.
- [Claude Code: Configure permissions](https://code.claude.com/docs/en/permissions) — Checked 22 October 2026. Manual mode, effective rules, saved approvals, read-only exceptions and hooks.
- [Git: git-worktree](https://git-scm.com/docs/git-worktree) — Checked 22 October 2026. Linked checkout and branch behavior; no application runtime isolation guarantee.