Organization settings

How it works

Eight tabs, grouped by what each decides.

Workspace defaults, the setup script every new workspace's container runs when it launches, on top of the built-in language toolchains: the extra packages and tools your work needs.

Board stages, the columns the workspace board is organized into: rename, reorder, add, delete. The column you mark as default is also the one that decides which workspaces may keep a box running, so there is no second setting to keep in step. A stage that still holds workspaces cannot be deleted, and the refusal names the column and its count.

Git flow, an ordered list of stages, each with a key, a label and a branch. The first stage is what work is cut from; promotion runs left to right; the last stage is production. Every branch in the flow is protected from direct agent pushes. A stage stores its key rather than its branch, so renaming a branch leaves merge requests already opened against it intact.

AI, which agent new workspaces start with, the Claude Code, Codex and OpenCode accounts every box runs on (add several per agent; when one hits its usage limit or its login fails, DevBench moves the box to the next account of the same agent and re-sends what failed), and the OpenAI key used to draft requirements, which never reaches a box. Its Coding agents list is which version of Claude Code, Codex and OpenCode the boxes run (CLI versions and one-click updates). This is also where the organization's standing instructions for every workspace live: the stack, the review etiquette, the library that must never be used again. They are seeded into every workspace's CLAUDE.md under a managed heading (a Codex box reads the same file as its AGENTS.md), and rewritten wholesale on each push, so editing the text converges every box instead of stacking copies in it, and clearing it removes the rule. Saving and applying are separate: Apply to all workspaces is what pushes it out, because a save that immediately rewrote every box would make a half-finished thought everyone's problem.

Integrations, your personal GitHub, GitLab and Bitbucket tokens, used to import repos and let workspaces push; the GitHub App; and the inbound webhook, where events from outside DevBench arrive.

Boxes, Box health (whether DevBench checks that a box's agent is not stuck), and the devbench CLI inside your workspace boxes, and reseeding it. The installers for your own machine are on Install DevBench, under ?.

Backup, see the next article. Plan and billing, what the organization uses against its plan.

Your own settings (what each click does, notifications on this browser, Lathe sharing) are not here: they are Preferences, in your menu.

Each workspace has its own settings too, General (running, archived), Automation (what DevBench does to it unasked), Git & merging (guardrails, self-merge), Security (what the box may reach beyond its repos), Agent rules (what the box enforces on the agent whatever it decides), Production alerts (how its deployed app reaches the team), and a Danger zone kept apart from the routine toggles on purpose.