Give each agent its own application state.

01Worktrees fixed the checkout, not the test environment

Reddit user Jhon_ST described working across roughly five Trello cards at once, with a branch and Git worktree per coding task. In their 27 September account, this stopped agents editing the same checkout. Browser QA still needed to establish which API, PostgreSQL database and worker it reached. The team added a service registry with process IDs, ports, URLs and declared database state, and kept integration serialized. That is an attributed workflow report, without a controlled speedup measurement. ⁸

To see the failure it is meant to prevent, consider hypothetical billing and signup agents. Their files live in separate worktrees, but their applications open the same local database. A billing migration test resets it while signup is reading a fixture. The patch may be correct and the reset intentional; the other task still loses its test data. This example is not an incident reported by Jhon_ST.

Supabase’s 14 October announcement describes an experimental local engine with a separate project for each worktree, requiring CLI 2.119.0 or later. Each project can reset, migrate and test its own database. This addresses the example’s shared-data problem; issue #53 kept the verdict at WAIT pending evaluation in the team’s own setup. ¹

02Check the endpoint the test actually reaches

Git’s worktree manual describes separate working directories, HEAD and index, while the repository remains shared. Repository configuration is also shared by default unless worktree-specific configuration is enabled. Those arrangements say where the source lives; the application’s database connection needs its own identity. ²

For billing and signup, compare the database each running process opens with its local project's reported endpoints. Supabase's endpoint guide shows supabase status, with --stack <name> for a named project. Two different environment files can still contain the same endpoint. ³

Supabase derives its local-project identity from the project root, Git branch and optional stack name. Different identities get separate local services and data; agents sharing one checkout and branch still share a local project. Its guide also warns about fixed-port collisions. Include the resolved endpoint in the task’s resource record, without copying credentials. ³

Jhon_ST’s registry addresses discovery: which worktree started which process? It does not establish API compatibility. A healthy service running an older branch can return valid responses that never exercise the new behavior. Before accepting a browser test, compare the expected revision and database identity with the service it reached, then repeat relevant checks on the combined tree. This follows the distinction the author makes between parallel feature work and serialized integration. ⁸

03Choose where the services run

Supabase recommends Docker or Podman for several local projects on one machine, giving them separate network namespaces and file systems. Its native runtime runs services as host processes, sharing the host process table and file locks. That mode is intended for one project per environment when a container engine is unavailable. The runtime choice is recorded when the project is created. ⁴

The billing and signup example therefore needs a machine as well as two branches. Both agents on one laptop and one agent in each disposable runner are different arrangements. Choose the runtime for the arrangement you will operate. A separate database also leaves a separate question: what else can either agent reach on that host?

The same thread includes a concrete alternative. On 28 September, commenter Something_Sexy said their team runs separate containers per worktree and has not found the resource requirement problematic so far, while noting that larger platforms may need a stronger machine. Their report offers an implementation choice, not a memory budget or evidence that containers alone fix database targeting. It reinforces the tradeoff: isolation has a host-resource cost that must fit the actual stack. ⁹

04Cancellation does not finish cleanup

Claude Code 2.1.301 fixes quitting that could remove a WorktreeCreate-hook worktree without asking, even when it might contain unpushed commits. Orca 1.4.227 addresses deletion of a folder that Git no longer tracks. These are vendor-reported fixes, not a record of failures in our hypothetical application. ^{6 7}

Now cancel the billing agent halfway through its task. Its diff, migration output and database may still matter to the person reviewing the work. Name the person or process allowed to remove each resource, and preserve unaccepted work before cleanup. The signup agent should continue against its own data while billing waits for review.

The database has its own lifecycle. Supabase distinguishes stopping a local project, which keeps its data and ports, from destroying one, which deletes its data. Docker also documents that a volume can survive removal of its container. Stopping billing therefore does not establish that its data is gone. A later cleanup job needs the current resource identity, rather than a remembered path or a port that another task may now use. ^{3 5}

05Try the collision before counting the speedup

A small trial can start with disposable billing and signup fixtures. Have signup repeatedly read its fixture through the real application launcher while billing resets its own database. Signup’s fixture should survive. Reverse the roles, then repeat after a resumed session and a cancellation. This is a proposed test; we have not run it here.

If signup loses its data, inspect the connection that process opened. A reused environment file, matching project identities or a fixed port may explain the collision. The result is actionable because it identifies the configuration that failed, rather than treating the agent’s completion message as proof that the tasks stayed apart.

Only then compare completed work. Run the same acceptance tasks serially and in parallel, including service startup, retries, review and cleanup in the time and cost. These releases do not tell us whether parallel agents will finish your work sooner. If preparing separate environments costs more than the interference it avoids, shared access with explicit coordination may suit that workload better.