2026 DeepSeek Harness Parallel Code Changes: Git Worktree Or Separate Clone?

The main question is not whether Git worktree is faster to create. The main question is which boundary needs to be isolated.

A Git worktree separates checked-out files, the index, and the worktree-specific HEAD. It does not automatically separate every repository setting, dependency directory, build output, running process, port, credential, or operating-system identity. Git describes linked worktrees as multiple working trees attached to one repository, with many repository objects shared between them. (Git worktree documentation)

DeepSeek Harness adds a stricter operational requirement for independent benchmark tasks: use separate workspaces and separate session IDs. The official benchmark guidance does not confirm that DeepSeek Harness automatically creates, binds, or removes Git worktrees. Any such orchestration should therefore be treated as an implementation policy, not as a built-in guarantee. (DeepSeek Harness benchmark guidance)

Use Git worktree when all tasks belong to the same trust boundary, can use compatible dependencies, and need short-lived branch-level isolation. Use a separate clone when the repository configuration, dependency state, credentials, or build outputs must not be shared. Use a separate account or remote Mac when the projects themselves have different security owners.

A directory name is not a task contract. Before launching a DeepSeek Harness session, record four fields:

1. Task owner.
2. Source revision or target branch.
3. Output branch.
4. Merge and cleanup owner.

For example, a platform service could assign:

task_id: ios-login-fix-184
source: origin/main
branch: agent/ios-login-fix-184
workspace: /srv/worktrees/ios-login-fix-184
session_id: dsh-session-<opaque-id>
cleanup_owner: platform-team

The session must receive the exact workspace path instead of discovering a repository directory by convention. The task should also state whether the agent may commit, whether it may push, and which checks must pass before the workspace is released.

This distinction matters because different tasks require different levels of workspace ownership:

• Code modification: exclusive ownership of the files it may edit, with a dedicated branch.
• Read-only analysis: a worktree may be enough, but the session should still receive its own workspace if tools create indexes, reports, or temporary files.
• Test repair: exclusive access to source files plus isolated test databases, fixtures, ports, and generated output.
• Build or release work: stronger separation may be required because signing files, archives, derived data, and tool caches can outlive the session.

Can multiple DeepSeek Harness sessions use one repository? Yes, but only when every session has a distinct workspace path and session ID, and the team accepts the shared repository objects and configuration that Git worktree deliberately retains.

A branch name alone is not sufficient. Two sessions using different branches inside the same directory still share the working files and can overwrite each other before Git has a chance to report a conflict.

The official Git syntax creates a linked worktree and can create a new branch at the same time:

git -C <main-repository> worktree add -b <task-branch> <workspace-path> <source-branch>

For a disposable experiment that should not immediately create a branch:

git -C <main-repository> worktree add --detach <workspace-path> <source-revision>

Git keeps separate administrative metadata for linked worktrees, while refs and repository objects remain shared in important cases. The HEAD and index are worktree-specific, but ordinary refs are generally shared. Repository configuration is shared by default unless worktree-specific configuration is enabled. (Git worktree documentation)

That produces a useful but limited isolation model:

• Files checked out under <workspace-path> are separate.
• The index is separate.
• The current HEAD is separate.
• The branch reference namespace is shared.
• The object database is shared.
• The default repository configuration is shared.
• External dependency and build directories may still be shared.
• Processes started by one session do not stop merely because its worktree is removed.

Git also prevents a branch from being checked out in two worktrees by default. That safeguard is valuable for parallel Agent work because it catches accidental branch reuse during workspace creation. Using --force bypasses that protection and should require an explicit platform policy. (Git worktree documentation)

How should parallel Agent changes avoid branch conflicts? Give every task a unique branch, create the worktree from a recorded source revision, and prohibit two active sessions from owning the same branch. If two tasks repeatedly modify the same files, directory separation will not remove the later merge conflict.

The most common failure is assuming that a separate worktree means a separate development environment. It does not.

Repository-level configuration

Git configuration is shared across worktrees by default. A repository-level setting that changes hooks, sparse checkout, ignored files, merge behavior, or tool integration can therefore affect more than one session. Git supports the extensions.worktreeConfig extension and git config --worktree for settings that should belong to one worktree, but this must be designed and tested rather than assumed. (Git worktree documentation)

Inspect the effective configuration before parallel execution:

git -C <workspace-path> config --show-origin --list
git -C <workspace-path> rev-parse --show-toplevel
git -C <workspace-path> rev-parse --git-common-dir
git -C <workspace-path> rev-parse --git-dir

The important review question is whether a setting points outside the workspace. A shared hook directory, generated configuration path, or global tool state can reintroduce cross-task effects.

Dependencies and package stores

Dependency installation is often the first reason to move from worktree to clone.

A package manager may place downloaded packages in a user-level or global store. For example, pnpm documents a package store that can contain packages used by multiple projects, and it provides pnpm store path and pnpm store status to inspect that store. The store can be shared safely as a content-addressed download source only when it is treated as immutable input and package installation still produces task-specific project state.

A shared download cache is usually acceptable when:

• The cache is managed by the package manager.
• The cache is read-only during the build, or the manager provides safe concurrent access.
• Each workspace has its own lockfile interpretation and installed-link structure.
• No task writes generated source or patched packages back into the shared cache.
• Cache ownership and pruning cannot remove files needed by an active task.

Use a task-level dependency directory when:

• The task applies local package patches.
• The build mutates installed files.
• Different tasks require incompatible toolchain versions.
• The package manager creates workspace links that point into a shared mutable directory.
• A failed task could leave modified dependencies behind.

Credentials are a separate issue. pnpm documents user-level authentication files, including a macOS location under ~/Library/Preferences/pnpm/, and warns that authentication settings are sensitive. A shared worktree does not make credentials safe to share, and a separate worktree does not create a new identity. (pnpm authentication configuration)

Build products, derived data, and ports

Build outputs must have task-level paths even when source files use separate worktrees. Xcode’s build system produces intermediate files and finished products, and Apple exposes settings such as DERIVED_FILE_DIR, PROJECT_TEMP_DIR, and custom derived data paths for controlling where those files are written. (Apple Xcode build system documentation)

A safe task contract should define values such as:

derived_data: /srv/build/<task-id>/derived-data
products: /srv/build/<task-id>/products
temp: /srv/build/<task-id>/tmp
test_database: /srv/build/<task-id>/test.sqlite
port_base: assigned by scheduler

The exact paths are placeholders. The principle is that no session should infer them from the repository root.

The same rule applies to:

• .env files generated for a session.
• Test databases.
• Browser profiles.
• Simulator data.
• Language-server indexes.
• Coverage reports.
• Generated API clients.
• Local Docker or virtual-machine volumes.
• Background watchers and development servers.

A worktree cannot stop a process that has already opened files elsewhere. Before cleanup, the platform must identify and terminate processes owned by the task, not simply remove the directory.

A separate clone creates another repository directory with its own .git metadata, refs, configuration, and object storage model. Git’s official clone documentation describes it as creating a new directory, copying repository history and references, and checking out an initial branch. It also documents options such as --single-branch, --filter, and --dissociate for controlling what is copied or borrowed. (Git clone documentation)

A separate clone is the better default when:

• The task needs different repository-level configuration.
• Dependencies must be installed and mutated independently.
• Build tools write into paths that are difficult to override.
• The team needs separate Git credentials or remotes.
• A task may run for days and should not depend on the lifecycle of a shared repository.
• Submodules or generated repositories make linked worktree behavior difficult to reason about.
• One task must be reset, fetched, or garbage-collected without affecting other tasks.

The trade-off is operational cost. A clone consumes more repository metadata and takes longer to initialize than a linked worktree, especially when the source is remote or the repository history is large. Do not invent a disk-saving percentage; measure the actual repository, dependency tree, and build products used by the team.

Is Git worktree suitable for long-running AI coding tasks? Only when the task remains in the same trust and toolchain boundary, has explicit ownership, and has a reliable lease and cleanup process. For a task that continuously changes dependencies, starts background services, or accumulates build state, a separate clone is easier to audit and recover.

Teams should not approve an Agent task solely because it has a different directory. The review contract should state:

• Which branch the task is allowed to modify.
• Whether the task may commit or push.
• Which files are exclusive to the task.
• Which caches are read-only.
• Which generated paths are task-specific.
• Which credentials are available.
• Who reviews the diff.
• What happens when the task is cancelled.
• Who owns an uncommitted result.

If two tasks have high-frequency edits in the same file, or if one task depends on the unmerged output of another, run them serially. Parallelizing those tasks moves the conflict from the editor into merge review, test interpretation, or runtime behavior. A separate clone does not eliminate semantic conflicts; it only prevents the sessions from directly mutating the same files.

A read-only analysis task can often run alongside a coding task, provided its index and report paths are separate. A test-fix task should not share a mutable test database with a feature task. A release task should not share signing material merely because both worktrees are on the same Mac.

DeepSeek Harness is currently a developer-preview project and its official repository describes rapid iteration with compatibility-breaking changes. The repository also documents session, credential, subprocess, and filesystem capabilities, but it does not establish that worktree lifecycle is automatically managed by the product. (DeepSeek Harness repository)

A platform team should own the complete lifecycle:

Create

1. Allocate a unique task ID.
2. Resolve and record the source revision.
3. Create a unique branch.
4. Create the worktree or clone at a generated path.
5. Configure task-specific build, temp, and report paths.
6. Bind the exact workspace path to the DeepSeek Harness session.
7. Record the session ID, branch, owner, and lease expiry.

Run

1. Confirm the session is operating inside the assigned workspace.
2. Confirm the branch and source revision.
3. Monitor child processes, ports, disk growth, and log paths.
4. Prevent a session from reading credentials outside its approved scope.
5. Store commits, patches, test logs, and exit status as task evidence.

Finish

1. Stop the session.
2. Stop child processes and release ports.
3. Run git status --short.
4. Save the diff, commit IDs, logs, and generated artifacts required by the task contract.
5. Decide whether uncommitted work is retained, exported, or rejected.
6. Remove the worktree using Git.

For a clean linked worktree:

git -C <main-repository> worktree remove <workspace-path>

For an unclean worktree, Git refuses removal unless force is used. That refusal is useful evidence, not an inconvenience to bypass automatically. Git documents that manually deleting a worktree directory can leave administrative metadata behind, which may later require git worktree prune; the supported removal path is git worktree remove. (Git worktree documentation)

If a directory was deleted outside Git, inspect before pruning:

git -C <main-repository> worktree list --porcelain
git -C <main-repository> worktree prune --dry-run

If cleanup fails, preserve the task record and hand it to a human when:

• The worktree contains uncommitted or untracked files.
• A process still has files open.
• The task owner has not approved discarding the result.
• The worktree metadata is locked or inconsistent.
• The repository has been moved and needs git worktree repair.
• The task used credentials or customer data that require an audit trail.

Choose Git worktree when the task is short-lived, uses the same repository and trust boundary, needs a unique branch, and can use shared read-only repository objects.

Choose a separate clone when dependencies, repository configuration, build outputs, credentials, or long-running background services must be independently controlled.

Choose a separate environment when projects have different customers, permissions, key sets, compliance owners, or data-classification requirements. That may mean a separate macOS account or a separate remote Mac. Worktree is version-control isolation, not a sandbox, container, identity boundary, or secret-management system.

Use this acceptance checklist before standardizing the design:

• [ ] Each active DeepSeek Harness session has one recorded workspace path.
• [ ] Each workspace has one unique task branch.
• [ ] Each session has one unique session ID.
• [ ] Two tasks cannot accidentally check out the same branch.
• [ ] Repository-level Git configuration has been reviewed.
• [ ] Dependency caches are classified as read-only, mutable, or forbidden to share.
• [ ] Build products and derived data use task-level paths.
• [ ] Test databases and temporary directories are task-specific.
• [ ] Ports and background processes are tracked by task ID.
• [ ] Credentials are injected per task rather than copied into the repository.
• [ ] A cancellation test confirms that child processes are stopped.
• [ ] A dirty-worktree test confirms that cleanup pauses for review.
• [ ] A successful task exports its diff, logs, and commit information.
• [ ] A failed cleanup preserves evidence and supports manual takeover.
• [ ] The team has tested two parallel modifications, one build, one cancellation, and one cleanup cycle.

Run the same benchmark task through all three modes: two linked worktrees, two separate clones, and two separate environments. Compare not only startup time, but also merge clarity, dependency reproducibility, build contamination, credential exposure, cancellation behavior, and recovery after an interrupted session.

A single existing Mac may appear cheaper than a managed remote setup, but it can become the limiting factor when every task needs separate build output, background processes, credentials, and human recovery. Shared local storage makes cleanup harder, a single user identity weakens project separation, and a busy machine can turn unrelated tasks into a scheduling problem. A separate clone improves repository control but does not create more CPU, memory, disk throughput, or independent macOS identities.

For a short experiment, the sensible next move is to create two disposable branches, run one modification and one build in parallel, cancel one session, and verify that the other workspace remains usable. If the current Mac cannot maintain independent workspaces or tasks remain active long enough for cleanup and process tracking to become burdensome, review the remote Mac environment planning guide and the Mac delivery options for parallel development before committing to a larger architecture.

NUKCLOUD is most relevant when a temporary remote Mac can provide a cleaner execution boundary than the current shared machine. It is not automatically the best choice for permanent, stable heavy workloads or projects that require dedicated physical interfaces; for those cases, owning a properly managed Mac may be simpler. For short-lived parallel DeepSeek Harness tasks, acceptance testing, and isolated customer work, a remote Mac can avoid the operational weaknesses of one overcrowded local host.

Start with the two-branch recovery test, record what actually collides, and let that evidence decide whether the next task receives a Git worktree, a separate clone, or a separate Mac environment.