Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

RFC: Isolated workspaces for agent team members

Aperta
  • Qualcosa non va?
#166 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
git, macos, typescript
Ambito
developer-experience, tooling

Direzione di ricerca

Start with the workspace and merge requirements in this RFC, then read src/utils/cwd.ts, AgentTool.tsx, resumeAgent.ts, and src/utils/worktree.ts to understand the existing spawn and worktree paths. The first scope calls for git worktree and macOS APFS clone providers. Done would require isolated member workspaces, change and base tracking, and a shared merge layer; the issue is research only and leaves key design questions open.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement rfc

Status

On hold since 2026-10-28. Research only; no design or implementation is scheduled. Part of the agent teams work in #162, which asks how the lead merges members' work and what happens on conflicts.

Why it is on hold:

  • The premise is not validated yet. The basic team flow does not work end to end (see #163, #164), so there is no data on how much several members working in one project gain, or how often they conflict.
  • The experiments showed no speed advantage. Scanning for changes and merging are cheap; preparing a workspace only pays off when a project has heavy build outputs.
  • A comparable tool takes a different route. rudderlabs/devbox runs one agent per repository and opens one PR per repository; it does not merge several members' work within one repository. It invests in single-task reliability instead: plan review gates, feeding PR comments and CI failures back to the agent, credential isolation, and committing knowledge with the PR.

When to resume: after the basic team flow works and has been used on a few real tasks. The first piece then is the smallest one: let the existing worktree isolation for subagents merge results back into the lead's directory.

The experiment log is in docs/agent-teams/infra/workspace-isolation-log.md on branch feat/workspace-isolation (commit 160a380).

Summary

Each member of an agent team needs its own copy of the project that it can read, write, build and test, and the members' results have to be merged back into the user's project. This RFC proposes one workspace provider interface that different isolation mechanisms implement, with a single merge layer on top that works the same on every platform.

The problem

  • Teammates have no directory of their own today. In-process teammates all work in the lead's directory. runWithCwdOverride (src/utils/cwd.ts) is only used by ordinary and resumed subagents (AgentTool.tsx, resumeAgent.ts); the teammate spawn path returns before isolation is handled.
  • A plain git worktree is slow to make usable. git worktree add checks out tracked files only. Ignored dependencies and build outputs are not copied, so every member reinstalls and rebuilds. In this repository the tracked files are 2,940 files and 44.7 MB, while the root node_modules alone is 40,987 files and 318 MB.
  • Worktrees also add a branch per member to the user's repository.

Isolation mechanisms

Mechanism How it works Platform Requirements
git worktree Extra working directory sharing the repository's object store All The project is a git repository
APFS clonefile(2) Copy-on-write clone of a whole directory tree in one call macOS Source and target on the same APFS volume
ReFS block cloning Copy-on-write per file and byte range Windows (ReFS, e.g. Dev Drive) Same ReFS volume; Dev Drive needs admin rights and at least 50 GB
ProjFS A user-mode process projects a directory; files fill in on first read Windows 10 1809+ Optional feature enabled by an admin; the projecting process must stay running
FUSE overlay User-space file system with a write overlay Linux; macOS and Windows only through Docker or WSL2 —
Copy Plain copy, dependencies shared through links All —

Measurements on macOS

Apple M1 Pro, APFS, copying this repository's root node_modules (40,987 files, 318 MB). Disk use measured with df before and after.

Method Time Extra disk
cp -R 51.3 s ~320 MB
cp -cR (per-file clonefile) 23.1 s ~0
One clonefile(2) on the directory 1.7 s ~25 MB (metadata)

Writing to a file in the clone left the original file's hash unchanged. Note that du and Finder count every clone at full size; df shows the real usage.

Proposal: a workspace provider interface

Merging needs three things: which files changed, each file's base version, and the member's version. Every isolation mechanism implements the same operations, and team scheduling and merging depend only on these.

Operation Purpose
Create Make an isolated copy for a member, return its path, and record the base
List changes Added, modified, deleted and renamed files
Read base A file's content at creation time
Reattach Restore an existing copy after the app restarts (a no-op for providers without a resident process)
Discard Delete the copy and free its resources
Capabilities Whether creation is instant, whether dependencies are ready after creation, whether dependency folders are isolated too, whether a resident process is needed

How each mechanism maps onto it:

git worktree APFS clone ProjFS (undecided) Copy
Create git worktree add, plus dependencies copied, cloned or linked in by the provider, or installed by the member One clonefile of the project Project a virtual directory Copy sources, link dependencies
Base The starting commit A second clone kept as the base A frozen snapshot (approach undecided) A copy of the starting sources
List changes git status / git diff Compare with the base File-change notifications Compare with the base
Resident process No No Yes No
Platform All macOS Windows All
Merge layer

One implementation for every platform. For each changed file, run a three-way line merge of the base, the current main directory and the member's version (git merge-file does this for a single file without needing a repository). On conflict, write the conflict markers back into the member's copy so the member resolves them and resubmits. Files over a size limit or binary files changed on both sides count as conflicts. Building and testing after a merge is a separate step.

Rules every provider follows

  • Members never commit to git themselves. A worktree shares the main .git, so member commits would land in the user's repository; clones and copies have their own .git, so commits would never come back. Results always come back through the merge layer.
  • Results exclude build outputs and dependencies, filtered by the project's .gitignore.
  • Preparing dependencies is the provider's job. It either has them ready at creation or declares that members must install them, so a team doesn't end up with some members able to run tests immediately and others spending minutes and tokens installing first. The fork already has .worktreeinclude (src/utils/worktree.ts) for copying ignored files into a new worktree.
  • One change format for renames, deletes, symlinks, binary files and permission bits.
  • Lifecycle is recorded on the server, so copies survive an app restart through Reattach.

The fork also has WorktreeCreate / WorktreeRemove hooks that let --worktree and EnterWorktree use a custom mechanism. They cover create and remove only, with no change list or base.

Suggested first scope

Two providers, to check that the interface doesn't lean towards one mechanism:

  1. git worktree: works on every platform without admin rights.
  2. APFS clone: macOS, ready in seconds, disk use grows only with changes.

Windows (ReFS block cloning, ProjFS) is on hold until it can be measured on Windows.

Open questions

  • Do absolute paths in build caches (tsbuildinfo, cargo incremental caches) force a rebuild in a cloned directory?
  • How does clone time grow beyond ~40k files, e.g. at 100k+?
  • How expensive is comparing tens of thousands of files with the base?
  • Should members pick up changes made to the main directory while they work, and how?
  • When several members merge one after another, which version counts as the current main directory for each, and how is a failed merge rolled back?
Lingua principale
TypeScript
Stelle
490
Fork
47
Merge medio
9h 31m
PR unite (30g)
76

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di GoDiao/dreamcoder

Tutte le issue di GoDiao/dreamcoder

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.