Why DevCell

Development environments now execute more code, hold more credentials, and operate with more autonomy than the container workflows they grew from. DevCell is designed around one premise: a workspace should not inherit the trust of its host.

Containers solve a different problem

Devcontainers are excellent at describing tools and dependencies. They make a project repeatable across laptops and editors. But sibling containers commonly share a host kernel, and convenience often leads to ambient access to sockets, files, credentials, and local services.

That tradeoff becomes harder to accept when a coding agent can build code, fetch dependencies, open ports, and act for hours without direct supervision.

The cell boundary

DevCell keeps the project formats developers already use while placing each workspace behind a dedicated machine boundary. The host—not repository code—owns policy and privileged resources.

requestRepository configcapability intent

→

authorityHost policyevaluate

→

grantCell capabilityscoped access

Denied requestsbecome audit events

This creates a simple hierarchy of trust:

• Repository configuration may request capabilities, never grant them.
• The DevCell Host is the trust anchor.
• Capabilities replace ambient host access.
• Lifecycle actions are typed, durable, and inspectable.
• Destroying a cell removes the workspace boundary without leaving project processes behind.

Why it feels familiar

DevCell is infrastructure around the development loop, not a replacement for it. Projects keep their devcontainer, Dockerfile, or Compose configuration. Developers keep their IDE, terminal, and agent. The new layer is a control plane that makes the machine boundary easy to create and disposable by default.