VS Code agent controls

Research date: 2026-10-10. Baseline: VS Code 1.141, released 2026-10-07. This is a dated product comparison and engineering assessment, not a Cella specification or a claim of completed integration. The assessment uses first-party Microsoft, VS Code, and GitHub sources. VS Code 1.141 release notes

VS Code already offers substantial agent control. Cella cannot credibly differentiate through approval prompts, sandboxing, multiple agents, session history, or keeping some credentials outside a sandbox alone. The useful question is whether Cella can deliver an independently enforced contract for private repository inputs, typed external Effects, secret-bearing Service Cells, generation-bound Channels, and verifiable delivery.

That remains a product thesis. Cella's current implementation does not yet deliver its full protected Agent Cell, Service Cell, Policy Engine, or Gateway Effect workflow. Compare working VS Code features against Cella's implementation today, and treat Cella's approved contracts as requirements to prove. Current implementation boundary, feature milestones

The Cella implementation snapshot below was refreshed against the 2026-10-11 milestones. Its partial local slices do not establish an accepted complete governed workflow; the external-product research remains dated 2026-10-10.

First distinguish the execution targets

“VS Code agent access” is not one permission system. A model selection is also not a harness selection.

The current Copilot worktree option uses Allow all. A worktree separates changes; it is not a security boundary. Codex on Agent Host exposes Default Permissions, Auto-Review, and Full Access presets. Copilot sandbox settings must not be assumed to govern Claude or Codex identically. Choose and use an agent harness, updated 2026-10-07

“Background” describes how work continues, not proof of confinement. Agent Host can own sessions independently of their viewer, and can run next to a local, container, or remote workspace. Its adapters retain distinct harness behavior. Agent Host architecture

Verified control surface

This matrix records documented behavior, not results from a penetration test. Preview and Experimental are feature labels, even when their controls appear in a stable editor release.

Version 1.141 adds automatic continuation of external Copilot conversations and same-machine Codex chat handoff between ChatGPT, Codex CLI, and VS Code. Only one application may send messages to a Codex chat at a time. 1.141 session continuation

Cross-harness handoff is also documented: conversation history and context can accompany a move from Copilot to Claude or Codex. This is broader than reopening a conversation in another viewer, but does not promise that every harness shares tool semantics, permissions, or hidden runtime state. Sessions and handoff, updated 2026-10-07

Copilot Agent Host defaults are part of the comparison

The following settings describe the default Copilot SDK tool implementation in Agent Host, not Local or a custom terminal override. Values can be narrowed by managed policy. Check the effective policy, not only saved preferences.

Developer-tool access can include credential-bearing configuration/caches. /sandbox policy reports the effective session policy. Linux/WSL2 require bubblewrap and socat; WSL1 is unsupported. Windows needs the applicable September 8, 2026 security update. Windows proxy/hostname/masking configurations require local-network access. Agent Host sandbox configuration, updated 2026-10-07

The GitHub reference additionally warns that Copilot CLI hostname rules and upstream proxies rely on programs honoring proxy settings on Windows; macOS/Linux prevent direct connections that bypass the proxy. Do not advertise identical domain confinement across platforms or infer every Agent Host path from CLI behavior. Managed sandbox network restrictions

A strict managed sandbox baseline combines these controls:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowBypass": false
  }
}

enabled alone can permit session bypass. Unsupported server-managed CLI hosts can decline it unless failIfUnavailable is required. This fragment does not configure all path, network, or credential restrictions. Managed sandbox semantics

What this means for Cella

How an agent gets permission to push a branch

A successful git push crosses three distinct gates:

1. Tool permission. The selected harness must permit the command. Manual approval, automatic approval, and managed restrictions differ by harness. Approval of a command does not itself supply credentials or repository rights. VS Code approvals
2. Network and authentication. The execution environment must reach the destination and authenticate. Copilot CLI's documented sandbox can supply placeholder Git credentials while a proxy inserts real authentication at the original HTTPS host, port, and repository path. Other harnesses need their own effective configuration checked. Copilot sandbox authentication
3. Repository rules. GitHub still applies repository permissions and branch protection, including configured push restrictions and required checks. A local approval cannot override them. Protected branches

Cella's intended delivery path adds an exact typed Effect bound to the selected candidate, repository, branch, policy, approval, and receipt. That contract is still incomplete; it must coexist with GitHub's own rules. This explanation was rechecked against the linked primary sources on 2026-10-11.

The assessments below are inferences and proposed priorities, not measured adoption outcomes or claims that other products cannot implement equivalent contracts.

Existing overlap removes several easy positioning claims

Agent HQ was announced on 2025-10-28 as a unified orchestration/control direction. The 2026-02-04 announcement introduced Claude and Codex integrations in public preview. These announcements establish the direction; use current product docs for today's availability rather than treating every launch promise as shipped. Agent HQ announcement, multi-provider preview announcement

Potential distinctions and the actual implementation gap

These are Cella-specific intended contracts, not proof of market uniqueness or superiority. Component architecture, governed capabilities, policy hierarchy, repository ingress and delivery, current milestones, Wall implementation, Gateway implementation, Relay implementation

Competition risk

High for generic agent workflow tooling. A session dashboard, selectable agents, reusable instructions, approvals, and a terminal wrapper face an integrated incumbent with established distribution. Additional interface polish will not establish an independent authority contract.

High for credential protection as a standalone pitch. Credential masking narrows the gap. Cella should demonstrate semantic authorization and reproducible consequences rather than claim that a hidden token alone solves agent authority.

Plausible opportunity for governed application workflows. An Agent Cell editing code while a separate Service Cell uses runtime secrets, with a bounded Channel and verified delivery, is a coherent use case. Its advantage must be demonstrated against a well-configured existing workflow, not an intentionally unrestricted strawman.

The largest immediate risk is Cella's implementation gap. A broader requirement catalog is useful for clarity, but it cannot compensate for a difficult installation or an unproven protected run.

Recommended integration direction

Keep VS Code as an editor and possible controller. Keep Cella as the authority and runtime owner. The following diagram is a proposed integration boundary, not an implemented connection:

VS Code UI / optional extension
        |
        | user intent, review, evidence view
        v
      cellad ----> Wall ----> Agent Cell (agent and execution tools)
        |                    |
        |<---- typed request-+
        |
        +----> Gateway ----> authorized external Effect
        |
        +----> Relay ------> generation-bound Channel ----> Service Cell

1. Start with a CLI workflow visible from the editor. Support one admitted agent and one private candidate; let users inspect the resulting patch and evidence in VS Code. Do not call launching a host agent from an integrated terminal “running inside Cella.”
2. Treat MCP as a transport adapter, not authorization. A proposed Cella MCP adapter may expose narrowly typed operations to an agent. Server trust, tool selection, and schema names do not prove Cell identity or grant an Effect. Derive identity from trusted endpoint state, validate exact arguments, and require the Cella authorization envelope. No generic secret retrieval, authenticated HTTP, host command, or unrestricted proxy tool.
3. Evaluate AHP after the core boundary works. A client could present Cella work/evidence alongside sessions, or a host adapter could connect supported session surfaces. Keep AHP subscription channels distinct from Cella Channels: shared session state is not a data-plane grant. Sequence/version compatibility and missing client tools need explicit treatment. AHP adapters must not become a bypass of cellad admission.
4. Inventory every execution path. Shell children, native read/edit tools, extension tools, MCP servers, language servers, browser/fetch tools, hooks, and external clients must be placed or denied deliberately. An agent inside a Cell with a host-side editing or terminal tool still has a host escape route through that tool. Approvals in two layers must remain intelligible; IDE approval cannot override Cella deny.

Avoid disabling native safeguards merely to reduce friction. A Cella integration should report where execution actually runs, which controls are effective, and whether the result is protected, offline-only, or unverified.

Concrete product and engineering actions

These are proposed acceptance work, not new canonical decisions or promises of release availability.

Limits and follow-up verification

This research verifies documentation, not live behavior on every operating system or subscription. Defaults can be overridden and features can roll out gradually. Record VS Code version, selected harness, OS, execution host, managed settings, and effective sandbox report in a comparison test.

Some official pages describe older Local behavior while newer pages describe Agent Host. In particular, do not reuse deprecated platform-specific sandbox settings, infer shell network behavior from the fetch/browser filter, or assume Copilot CLI masking automatically covers all VS Code tools. Recheck the target-specific configuration before publishing an installation example.

The monitoring guide's Agent Host identity-capture note differs from the 1.141 release notes, which announce managed identity capture. Treat that as a version/configuration verification item rather than promising uniform telemetry. Monitoring scope, 1.141 enterprise identity capture

All linked primary sources were checked on 2026-10-10. Dated announcements are historical milestones; GitHub documentation without a publication date is cited as current documentation retrieved on that date. Revisit this comparison when a supported harness changes its boundary or Cella completes an acceptance gate.