Project environments

Each agent keeps a config directory (auth, settings, history). The one a session uses decides whose account touched the code. Slate sets the account per workspace, with an override on a group or on a project that stands on its own.

• A project inside a group uses its group's.
• A project that joins a group drops its own and takes the group's.
• A project that leaves a group keeps a copy of the group's, so it runs under the same account.
• A new group takes the settings of its first project that has its own.

How it works#

In Connect → Agents choose, per tool, the account this workspace runs it under. A group or project can override it (most never need to). There is one account per tool per group or project; what runs picks a tool and its place supplies the account. Automations, Home turns and skill steps store no login, and moving a skill re-points it.

The same switch installs Slate into that account, which gets its sessions captured. A config directory exists once per machine, so workspaces naming it share the sign-in.

Which folders it covers#

A group or project covers its own folder and the folder of every project in it. A session is judged by the deepest folder containing it.

What it governs#

• Sessions started from Slate. A session runs as the workspace its place belongs to, whichever workspace the window shows. A work project started from Personal runs on the work account.
• Home, when scoped to the group or project.
• Automations and skills that belong to it, including scheduled runs nobody watches.
• Sessions you start in a terminal. Slate installs hooks into each account, through the tool's own plugin or config file. They refuse the first prompt of a session running under an account the group or project does not use.

A group or project with no tools of its own (most of them) is judged by its workspace's accounts, in the terminal and in Slate. One limit: only an account that another workspace or project on this computer uses is refused. A Personal login in a work folder is stopped. A third login no workspace names still runs. A tool the workspace does not list is never refused.

A model is a starting point, not a limit. A group or project can set a default model per tool, and any model may still be used.

What it cannot govern#

• OpenCode. It has no documented config-directory variable, so it cannot be pinned. CLAUDE_CONFIG_DIR, GEMINI_CLI_HOME, CODEX_HOME and CURSOR_CONFIG_DIR are the four that exist. OpenCode is captured, not governed, and its row says so.
• A group or project with no folder. A terminal session is matched by working directory.
• A broken Slate. Enforcement fails open: an unreadable setting or a crashed hook lets the prompt through.

How you know it's working#

A group's doc, and the doc of a standalone project, shows one line above its tabs: "3 captured sessions ran under the accounts this project assigns." When some did not: "1 of 3 captured sessions ran under an account this project does not assign." Review lists up to five, each with the account it ran under and the one expected. The line appears once the group or project has an environment and one captured session.

See also#

• Agents & Model Providers: the tools these environments configure.
• Connect: the screen this is set on.
• Toolkit: the wider "configure once, use everywhere" story.