Operate coding agents across editors and isolated workspaces

This worked application uses explicit planning assumptions to demonstrate FIELD. Quantities below are inputs, calculated implications or proposed targets; they are not reported customer results. The engagement decision remains conditional on the evidence described.

Planning basis and engagement boundary

F — Frame the outcome

Deliver reviewable repository changes that reduce maintainer effort while preserving merge authority and honest test evidence.

Value measure: Reviewer time per accepted patch and sandbox cost with regression/access guardrails.

I — Investigate the workflow

Observe environment setup, reviewer needs and issue suitability; classify repository/tool content as untrusted and identify necessary capabilities.

First evidence task: Cancel a test subprocess, reconnect the editor and verify status and cleanup.

E — Engineer the solution

Use ACP as an interaction adapter plus isolated resource-limited execution and patch-bound evidence; size normal and failure-mode sandbox capacity.

The implementation assessment below makes the authority, workload, resource and failure assumptions concrete. Its numbers are calculations from the stated scenario, not a vendor performance guarantee.

Implementation plan

Use an Agent Client Protocol adapter for editor interoperability where supported, but keep your internal run model independent of the editor protocol. Pin a compatible client/SDK version. Accept an explicit repository/base revision and create an isolated workspace with only required files. The model receives task context and bounded tooling; the execution service owns path policy, subprocesses, timeouts, mounts and egress. Treat repository instructions, downloaded content and tool output as data of bounded authority. Skill packages are versioned inputs, not permission grants.

The harness plans edits, applies them to its workspace, runs relevant checks and gathers evidence. Store patch/base digest, changed files, commands, exit status, log references and test collection details. Distinguish “not run,” “failed,” “passed with scope” and “inconclusive.” A patch is reviewable output; merging, publishing or external side effects require the product's separate authority contract. Avoid storing full credentials or unnecessary customer code in traces.

For disconnects, retain durable run state and reconnect through supported session behavior. Decide explicitly whether a user cancellation stops the sandbox job or only detaches the client; then implement that contract. Process-tree cleanup must reach subprocesses and prevent orphan jobs. A run that died before tests finished cannot reuse an earlier pass from a different patch digest.

Machine and filesystem budget

Twenty fully utilized sandboxes require twenty vCPU of quota and up to forty GiB of task memory, plus host/runtime overhead and disk cache. Two 16-vCPU/32-GiB hosts provide a possible normal-operation starting point at ten tasks/host, but do not preserve all twenty task slots after losing one host. Add a third appropriately sized host or reduce failure-mode admission, then load-test scheduling and headroom.

Repository clones, dependency caches, test output and artifacts can dominate disk bandwidth and space. Bound bytes/inodes, avoid unsafe cross-tenant writable caches and measure cold-start versus warm-start time. Native test libraries can oversubscribe cores internally; configure thread counts against quotas. CPU throttling increases elapsed time even when code is healthy. No GPU is required for the editor protocol; local model inference is sized separately.

Failure and evaluation

Test path traversal/symlinks, malicious repository instructions, runaway processes, large logs, workspace disk exhaustion and dependency installation failures. Restrict network destinations according to product needs; do not silently give generated code access to the host's credentials. A container may be sufficient for one threat model; stronger isolation is appropriate for hostile code sharing infrastructure. State the assumption.

Measure task correctness on held-out repository problems, regression rate, unauthorized access attempts, edit/test latency, peak resources and cost per accepted patch. Verify that tests actually cover the changed behavior; an unrelated green suite is weak evidence. Compare agent runs using identical repository revisions and checks.

If the scope changes: The task needs GPU-based model tests. Introduce a separately scheduled accelerator job class with GPU memory limits, model/data provenance, queue fairness and explicit cost; do not reserve an accelerator for every editor session.

Simpler alternative: For a local trusted single-user tool, use a local isolated checkout and restricted subprocess runner initially. Explain which assumptions prevent safely reusing that design for a multi-tenant hosted service.

L — Launch with evidence

Test disconnected clients, stale bases, cancelled checks and prohibited access. Compare accepted-patch effort and regressions with the current workflow.

Critical decision condition: Unrun tests labeled passed or sandbox escapes block release.

Attach raw artifacts, the tested configuration, population, denominator, date and limitations to the release record. Missing or stale evidence holds the dependent decision. A favorable value forecast cannot offset a failed critical condition.

D — Develop ownership and reuse

Maintainers own acceptance; the execution owner runs cleanup/recovery and a second operator reproduces the evidence bundle.

Candidate reusable asset: Editor-independent patch/evidence contract.

Commercial decision and next commitment

Accountable decision owner: Repository owner with sandbox service owner.

The initial commitment is the bounded journey above, with the stated exclusions. Confirm access, customer staffing and acceptance ownership during discovery; price and schedule unresolved dependencies explicitly. A new source, tenant class, language, action or operating envelope requires an impact review rather than silent scope growth.

Approve only the next exposure level supported by the evidence. The next useful investment is: cancel a test subprocess, reconnect the editor and verify status and cleanup.

Method and references

Apply the FIELD method, economic model and evidence rules. Methodological and technical influences are listed in the source register. The protocol assessment follows the agent control chapter; pin and verify the actual protocol/runtime combination before implementation.