Two agents can use different folders and still collide

An agent is updating a checkout form while another adjusts the same application's test fixtures. Putting each task in a Git worktree can keep their source edits separate. It does not automatically give them separate databases, credentials, network permissions, or development-server ports.

The practical question is not whether worktrees or containers are better. It is which boundary the task needs. Our recommendation is to name the source boundary, runtime boundary and service boundary independently before the agent starts executing commands.

This guide is for developers evaluating coding skills and setting up concurrent work. It is not a recipe for running unknown code on a production machine.

Selection methodology

We reviewed the Git worktree manual and Docker's runtime and bind-mount documentation on September 14, 2026. The comparison follows one hypothetical task through editing, execution and review. No containers, third-party skills or adversarial workloads were executed for this article.

We compare what each mechanism separates, what remains shared and what evidence a teammate needs to reproduce the result. We do not rank tools by popularity or claim measured speed improvements.

When evaluating a candidate in the OpenAgentSkill directory, look for an explicit environment contract. A phrase such as isolated workspace should lead to a description of what is actually isolated.

Use a worktree to separate the change

The Git worktree manual describes multiple working trees attached to one repository. Linked worktrees have their own checkout-related state while sharing repository data. That supports separate changes without repeatedly switching the main working directory.

For our checkout example, assign each task a distinct branch and absolute directory. Record the starting commit and which files belong to the task. Do not assume uncommitted work in the original checkout appears in a new worktree; decide explicitly whether the task starts from committed code or an approved snapshot of current changes.

This is source organization, not a new operating-system identity. If both agent processes run with the same host permissions, a different directory name does not prevent either process from reaching another accessible path.

Also name the eventual integration owner. Separate branches still require conflict resolution and a test of the combined change. Two individually passing branches are not evidence that the merged application passes.

Use a container to specify execution conditions

Docker's container runtime documentation exposes controls for the image, networking, user and resource constraints. These settings describe execution conditions that a Git branch does not provide.

A proposed container contract should identify the exact image, intended user, CPU and memory limits, allowed network behavior and the command being run. Avoid describing an environment as constrained when those details are unknown.

For a familiar, reviewed project, a worktree with an already approved development environment may be sufficient. If tasks need incompatible system dependencies, a container can make those environments easier to distinguish. For untrusted execution, stop and obtain a security-reviewed environment appropriate to the threat model; adding a container label is not a complete security assessment.

Keep execution costs visible. Extra images, dependency downloads, caches and parallel test processes consume resources. A container does not remove model usage or external service charges.

A mounted folder can reconnect the boundaries

Docker warns that bind mounts have host write access by default. A process inside a container can therefore change files in a writable host mount. Read-only mounts restrict writes to that mount, but do not turn every other resource into a read-only one.

Our recommendation is to list mounts before starting the task. For each, identify its host path, container path, purpose and write permission. Reject broad convenience mounts when a narrow task folder would do. Do not pass unrelated credential directories into a test environment.

There is a further practical worktree detail: linked worktrees refer to shared Git metadata. Mounting only the visible source folder may not be enough for Git commands inside a container. Verify the intended Git access without casually exposing the whole host repository tree. An exported source snapshot is another option when the task only needs to build or test, not manipulate branches.

Give shared services their own names

Return to the two-agent checkout task. Even with separate worktrees and containers, both jobs could point to the same test database.

Before execution, write a small task receipt:

Source: branch, starting commit, absolute checkout path and requested change.
Runtime: image or host environment, dependency state and permitted command.
Services: test database or namespace, output directory and assigned port.
Authority: allowed external actions and operations that require approval.
Evidence: expected logs, diff and acceptance checks.

For the fixture task, use non-production data and an explicitly assigned test service. If separate services are unavailable, serialize the conflicting operation instead of pretending the jobs are independent. A collision is a coordination problem, not a reason to grant more permissions.

Review the artifact before cleaning up

The handoff should contain the final diff, exact commands actually run, observed outcomes and unresolved checks. Distinguish a test that failed from one that was not run because its environment was unavailable.

Before merging, compare each task's starting point with the integration branch and review the combined behavior. Preserve useful logs and uncommitted work before any cleanup. This article does not authorize automatic branch deletion, forced worktree removal or discarding another task's files.

For dependency evidence, pair this receipt with our Python skill dependency handoff. A reproducible dependency description and a bounded execution environment answer different questions.

Limitations

The right runtime boundary depends on the host, container configuration, data sensitivity and threat model. This guide does not establish that a particular container configuration is secure or that a skill is safe to execute.

Start with the smallest authorized setup that covers the actual task. Worktrees organize changes; runtime controls restrict execution; separate service assignments prevent shared-state conflicts. Treat all three as explicit decisions, and report the boundaries you verified rather than the isolation you hoped to have.