A box is a full Linux machine, so you can develop in it the same way you would on any remote host. This page covers the everyday loop: opening an interactive shell, keeping work alive with tmux, connecting over SSH, and attaching the editors and agents you already use — Zed, VS Code, Claude Code, and Codex. For the underlying lifecycle and flags, see Boxes; for the in-box runtime, see Environment.

Interactive shell with console

The fastest way into a box is zomg console. It opens an interactive login shell with a TTY and drops you in /work:
zomg console my-box
console is built for interactive use — it forces a TTY and raw mode by default, inherits your TERM, and runs as root unless you pass --user. A few common variants:
# Open a shell as a project user (shared /home/<user>)
zomg console --user alice my-box

# Run one command with a TTY instead of a login shell
zomg console my-box --command "bash -lc 'vim /etc/hosts'"

# Throwaway box that is deleted the moment you exit
zomg console -
See Exec and console for the full flag list.

Keep sessions alive with tmux

zomg console is a live connection: if your laptop sleeps, the network drops, or you close the terminal, the shell goes with it, and anything running in the foreground dies. dev-base (and box-base) ships with tmux, so run your work inside a tmux session and it survives disconnects.
Always start long-running or interactive work inside tmux. The box keeps the tmux server running even after you disconnect, so you can reattach and pick up exactly where you left off.
Start or attach to a persistent session in one command:
# Attach to a session named "main", creating it if it doesn't exist
zomg console my-box --command "tmux new-session -A -s main"
Inside tmux, detach with Ctrl-b d — your processes keep running. Run the same command again to land back in the session. List what’s there with tmux ls:
zomg console my-box --command "tmux ls"
This pattern is especially useful for dev servers, build watches, and long agent runs you want to leave going while you step away.

SSH

zomg ssh connects to a box through the SSH gateway. On Unix it execs into your real ssh client, so keys, agent forwarding, and config all behave exactly as they would for any host:
zomg ssh my-box

# Forward your SSH agent
zomg ssh my-box -- -A

# Verbose, with a specific key
zomg ssh my-box -- -v -i ~/.ssh/id_ed25519
The connection resolves to a normal ssh invocation. The username is <project>--<box>, the gateway host comes from your profile, and the default port is 2222. Print the exact command without connecting:
zomg ssh my-box --info
# ssh -p 2222 default--my-box@ssh.zomg.example.com
This is the key to wiring up external tools: anything that speaks SSH can connect to a box as long as it uses that username, host, and port.

A reusable SSH config entry

External editors and agents connect best through a named ~/.ssh/config host. Take the values from zomg ssh my-box --info and add an entry:
Host my-box
  HostName ssh.zomg.example.com
  User default--my-box
  Port 2222
  # Optional: forward your agent so git inside the box uses your keys
  ForwardAgent yes
Now ssh my-box works directly, and every tool below can target the host alias my-box.
The box’s pod IP changes on stop/resume, but the gateway host and your ~/.ssh/config entry do not — reconnect after a resume and you’re back in.

Connect your editor or agent

Each tool below connects over the same SSH gateway. Set up the SSH config entry first; then point the tool at the host alias (my-box).

Zed

Zed’s remote development opens a project on a remote host over SSH and runs the Zed server there for you.
# Open a directory in the box directly from the terminal
zed ssh://my-box/work
Or use cmd-shift-pprojects: open remote in Zed and pick the my-box host. Zed installs and manages its server-side component for you on first connect.

VS Code

VS Code offers two ways to work in a box. Remote - SSH (docs) connects your local VS Code to the box and runs the VS Code server there over SSH. Install the Remote - SSH extension, then:
# Open VS Code connected to the box, in /work
code --remote ssh-remote+my-box /work
Or run Remote-SSH: Connect to Host… from the command palette and choose my-box. VS Code Server (docs) runs a server inside the box that you reach from a browser — handy when you can’t install the desktop app locally. dev-base ships the VS Code CLI (code), so you can serve the web UI from within the box:
# Inside the box (e.g. via `zomg console my-box`)
code serve-web --host 0.0.0.0 --port 8000
Then expose port 8000 with a service and open the published URL in your browser. The same code binary also supports secure tunnels via code tunnel if you prefer connecting through a tunnel instead of publishing a port.

Claude Code

Claude Code can run over an SSH session: connect to the box, then launch claude there. dev-base already has @anthropic-ai/claude-code installed globally, so no setup is needed inside the box:
zomg ssh my-box
# now inside the box
cd /work && claude
You can also drive Claude Code in the box non-interactively from the desktop app’s SSH sessions feature by pointing it at the my-box host. To keep Claude Code signed in across boxes, use the dashboard developer profile to sync Claude credentials or ANTHROPIC_API_KEY into a project user’s shared home. See Coding agent auth.

Codex

Codex supports remote connections to an SSH host. dev-base installs @openai/codex globally, so connecting Codex to the my-box host runs the agent inside the box. To run it directly:
zomg ssh my-box
# now inside the box
cd /work && codex
If you want Codex to use your local credentials inside the box, copy them in first:
zomg inject my-box
zomg inject writes ~/.codex/auth.json and config into the box (see Boxes → Inject credentials). For repeatable Codex auth on a project user, use the dashboard developer profile instead. It syncs ~/.codex/auth.json into /home/<user> so the login survives box deletion. See Coding agent auth.

Agent observability

Boxes inject OpenTelemetry defaults for Claude Code and other tools that honor standard OTEL environment variables. Claude Code telemetry, trace export, and prompt logging are enabled with OTEL_LOG_USER_PROMPTS=1. Zomg also writes a Codex OTEL template at /etc/zomg/codex-otel.toml with log_user_prompt = true. Add that block to ~/.codex/config.toml when you want in-box Codex sessions to export logs, metrics, and traces to Zomg observability. Search traces with:
zomg observability traces my-box --agent claude --since 1h
zomg observability traces my-box --agent codex --session <session-id>
zomg observability trace <trace-id>

Logging conventions

Zomg runtime logs should go through the shared helpers for their runtime:
  • Rust services (zomg-api, zomg-agentd, and zomg-ssh-gateway) initialize zomg_service_common::init_logging(...) and log with tracing.
  • TypeScript server runtimes use @zomg/logging and create a component logger with createLogger("component-name").
  • Shell deploy/setup scripts that source scripts/shared/lib.sh use log for progress messages and fail for fatal errors.
Command output is different from logging: CLI responses, JSON extraction helpers, and generated files can still write directly to stdout when callers consume that output. just check runs scripts/check-logging-consistency.sh to keep these rules consistent.

Next steps

Boxes

Create, exec, console, and ssh into boxes from outside.

Environment

The in-box runtime: PATH, /box/* volumes, env vars, and DNS.

Services

Expose a box — like VS Code Server — on a public URL.

Exec and console

Full flag reference for exec, console, ssh, and logs.