How to Share a Dev Environment with Your Team

Published July 26, 2026 · by the AQ team

Sharing a dev environment with your team means one of two different things, and picking the wrong one wastes weeks. If the goal is that every teammate can rebuild the same environment, you share the recipe: a devcontainer.json or a Nix configuration committed to the repository, optionally run on a cloud platform like GitHub Codespaces or Coder. If the goal is that a teammate can see and touch the environment you have running right now (your shell, your processes, your half-finished state), you share the running instance: VS Code Live Share, a shared tmux session on a server, or a harness that streams live sessions to the browser. This guide covers both, and how AI coding agents change the calculus.

The two problems people call "sharing an environment"

Sharing the recipe is a reproducibility problem. A new hire should get a working setup in minutes, not days, and "works on my machine" should stop being a sentence anyone says. A GitLab survey found 61 percent of developers troubleshoot their environment at least monthly.

Sharing the running instance is a handoff problem. You are three hours into a debugging session, or an agent is mid-task in your terminal, and a teammate needs to take over, unblock you, or just look. Rebuilding from the recipe gets them a fresh copy; they need yours, with its state.

Most teams need both; the mistake is expecting a tool for one to solve the other.

Share the recipe with a devcontainer.json in the repo

The closest thing to a standard is the open Development Containers specification (containers.dev): a devcontainer.json file in your repository that declares the base image, tools, extensions, and lifecycle hooks for a containerized environment. As of July 2026 the spec is supported by VS Code (the Dev Containers extension), GitHub Codespaces, DevPod, a reference CLI you can run in CI, and JetBrains IDEs.

mkdir .devcontainer
cat > .devcontainer/devcontainer.json << 'EOF'
{
  "name": "api",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:22",
  "features": {
    "ghcr.io/devcontainers/features/docker-in-docker:2": {}
  },
  "postCreateCommand": "npm ci"
}
EOF
git add .devcontainer && git commit -m "add dev container config"

Anyone who clones the repo and has Docker gets the same environment, and the config reviews like code because it is code. Reusable "Features" (self-contained installers for tools like a database client or a language runtime) keep per-repo configs small. The costs: everything runs in a Linux container (fine for most web work, awkward for iOS), Docker on a laptop eats RAM, and the recipe drifts unless someone owns it.

Share the recipe without containers: Nix, Devbox, devenv

The Nix ecosystem solves the same problem at the package level instead of the container level: a declarative file pins exact versions of every tool, and the environment activates in a plain shell on macOS or Linux, no Docker daemon required. Raw Nix has a famously steep learning curve, so most teams adopt it through a friendlier wrapper: Devbox (open source, from Jetify) gives you a devbox.json and commands like devbox add nodejs, while devenv (open source, from Cachix) adds services, processes, and git hooks in a devenv.nix. Both fit teams that want reproducibility with native performance and no Docker daemon.

Move the environment off laptops: cloud development environments

A recipe still leaves every developer running their own copy locally. Cloud development environments (CDEs) run the recipe on a server instead, which standardizes hardware, keeps source code off laptops, and makes environments disposable. The market as of July 2026:

• GitHub Codespaces runs your devcontainer.json on GitHub-managed VMs. Compute starts at 18 cents per hour for a 2-core machine and scales with core count; storage is 7 cents per GB-month; personal accounts include 120 free core hours a month. Zero infrastructure to run, but per-hour billing adds up for always-on use, and everything lives in GitHub's cloud.
• Coder is the self-hosted route: an open-source platform where a platform team defines workspaces as Terraform templates and developers provision them on your own AWS, GCP, Azure, or Kubernetes. You operate it, and you get custody and cost control in exchange.
• DevPod is an open-source, client-only tool (no server component) that spins up a devcontainer.json environment on whatever backend you point it at: local Docker, Kubernetes, SSH hosts, or cloud VMs it creates and auto-shuts-down. Cheap and unopinionated.
• Ona, formerly Gitpod, rebranded in September 2025 and pivoted from classic cloud IDEs to sandboxed environments for AI agents. In June 2026 OpenAI announced it was acquiring Ona to power long-running Codex tasks (the deal had not closed as of July 2026). Evaluate it as an agent platform, not a classic CDE.

Share the running instance: Live Share, tmux, tunnels

None of the above lets a teammate into the environment you have open right now. For that, as of July 2026, the manual toolkit is:

• VS Code Live Share (free, from Microsoft) shares your editor session: guests co-edit, use your terminal, and hit your localhost ports through their own VS Code, without installing your dependencies. It follows your editor process, so the session ends when your laptop sleeps.
• A shared tmux session on a server. Two people who can SSH to the same machine as the same user can both run tmux attach on one session and see the same live terminal. This is the classic pairing setup: real, byte-for-byte shared state, and it survives either person disconnecting. The costs are SSH account management, no easy read-only mode, and zero visibility for anyone who does not log in.
• Tunnels for showing the app. When the teammate only needs to see the running dev server, a tunnel (Cloudflare Tunnel, ngrok, or Tailscale between machines) exposes your localhost port to them without sharing the environment at all.

What changes when AI coding agents live in the environment

Coding agents turn the handoff problem from occasional to daily. An agent session (Claude Code, Codex, or similar) is long-running state: hours of context, a terminal mid-conversation, processes it started. When that lives on one person's laptop, nobody else can see what the agent is doing, steer it, or pick it up when the owner goes to lunch, and the session dies with the lid. The recipe tools in this guide do nothing for this, because the thing worth sharing is precisely the running instance. Teams solve it manually with the server-plus-tmux pattern above (see our guide to keeping Claude Code running after you close your laptop), plus git worktrees so parallel tasks do not collide, plus a tunnel when someone wants to see the app the agent built.

The options at a glance

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this guide's terms, AQ is the sharing-the-running-instance column, productized for agent work. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser: sessions survive a closed laptop, resume from any device, and any teammate can open the same workspace and see and steer the same live session, without SSH account juggling.

The recipe side stays conventional and yours: each workspace gets its own isolated git worktree with automatic dependency install, each engineer signs into the CLIs with their own Claude or OpenAI account (AQ never marks up model usage) and uses per-user GitHub auth to commit, push, and open PRs. Every workspace can run a live dev-server preview with shareable and guest links, so "come look at this" is a URL, and comments pinned on the preview (screenshots included) can be sent to the agent as prompts. Label a Linear issue ai-task and a workspace appears with status syncing both ways. There is no shared multi-tenant execution tier: the Free plan is the full product on a VM you bring (you pay only your cloud provider), and the Team plan ($100 per user per month promotional, standard $200) includes a dedicated always-on AQ-managed VM in its own isolated network, rate locked for your first 12 months.

Plainly: if your problem is onboarding and drift, commit a devcontainer.json or a Nix config first; that is free and you should do it regardless. AQ earns its place when the thing your team keeps needing to share is the live, running session an agent is working in.