Prevent the Wrong Account in a Repository

The usual way an account boundary breaks isn’t a leaked credential. It’s a terminal tab left on your personal accounts, opened in a work repository, where you start claude without looking. The agent then runs under the wrong subscription, the wrong organization policy and the wrong audit trail, on code that account should never see. Workspace guardrails turn that silent mistake into a warning or a blocked launch.

How it works

Three pieces fit together. A profile holds one saved account for one tool. A context groups one profile per tool, such as work for your work Claude Code and Codex CLI accounts. A workspace rule says which context a directory expects. The profiles vs. contexts guide covers the first two.

The shell hook that aisw init installs defines claude, codex, gemini, and agy as shell functions. Each one runs aisw workspace check before starting the real binary. If the current directory resolves to an expected context and the active profiles don’t match it, the check warns or refuses, depending on the guard mode. The hook also runs the check whenever you change directory, so a mismatch shows up before you type the agent’s name.

Set it up

1. Create the context the repository should use.

aisw context create work --claude work --codex work

Map only the tools you use there. A context can cover one tool or all four.

2. Bind the repository.

cd ~/code/work-app
aisw workspace bind . --context work

Inside a Git repository this writes the binding to .git/info/aisw.json in that clone, so it is never committed and is lost if you delete and re-clone. To cover every repository from one organization, including ones you clone later, bind the Git remote pattern instead.

3. Check what aisw resolved.

$ aisw workspace status
Workspace
  Workspace     : ~/code/work-app
  Repo root     : ~/code/work-app
  Expected      : work
  Active context: personal
  Status        : mismatch
  Matched rule  : repo_local:~/code/work-app/.git/info/aisw.json
  Action        : aisw context use work

Matched rule tells you which rule won, and Action is the command that fixes a mismatch. This is where you catch a misspelled context or a binding made from the wrong directory.

4. Turn on enforcement.

aisw workspace guard --mode strict

The guard mode is global: it applies to every bound directory. It starts as warn, so a binding warns from the moment you create it.

Roll out warn mode before strict mode

If you are adding guardrails to repositories you already work in, stay on warn mode for a day. With the wrong context active, entering the repository prints:

Workspace guard: expected context 'work', current state 'personal' (mismatch). Run 'aisw context use work'.

and launching an agent prints a warning, then starts it anyway:

$ claude
Workspace guard warning: expected context 'work', current state 'personal' (mismatch). Run 'aisw context use work' before launching Claude Code.

Try it with each agent you use, and from every terminal you launch agents from, including the integrated terminal in VS Code or Cursor. Once the warnings appear where you expect them and nowhere else, switch to strict mode.

What strict mode does on a mismatch

$ cd ~/code/work-app
$ claude
Error: workspace guard refused to launch Claude Code.
  Expected context: 'work'
  Current state: 'personal'
  Status: mismatch
  Run 'aisw context use work'.

The agent never starts. Run aisw context use work and launch it again. Current state shows the active context’s name when the active profiles match one, and the profile per tool (claude personal, codex none, ...) when they don’t.

The guard treats more than a plain mismatch as a problem:

In each case strict mode refuses and warn mode warns. Only match, or a directory with no expected context, lets the agent start silently.

Path rules vs. repository bindings

aisw workspace bind <path> behaves differently depending on what the path is:

• Inside a Git repository, it writes a repo-local binding to that clone’s .git/info/aisw.json.
• Outside a Git repository, it saves a path rule to ~/.aisw/workspaces.json, and every directory underneath matches it. This suits a folder that holds many repositories:

aisw workspace bind ~/work --context work

When several rules could apply, aisw takes the first match in this order:

1. Repo-local binding in .git/info/aisw.json
2. Path rule, choosing the deepest matching directory
3. Git remote pattern
4. Default context from aisw workspace bind --default --context <name>

To remove a rule, run aisw workspace unbind with the same path or --git-remote pattern. aisw workspace doctor checks your path, remote, and default rules and fails any that point at a context that no longer exists.

What the guard does not cover

The guard is a shell function, so it only runs where the hook is loaded. It doesn’t check:

• command claude, or any call to the binary by its full path, since both skip the shell function.
• Agents started without going through your shell, such as a chat panel in an IDE extension.
• Shells started before aisw init added the hook. Open a new terminal, or source your rc file.

It also never switches accounts by itself. It reports the expected context and leaves the switch to you.

Desktop method

The current public AI Switcher Desktop release covers macOS, Windows x64, and Linux x64. Download the matching build from the download page, then use Diagnostics to catch and repair repository mismatches.

The Diagnostics screen lists every mismatch across your bound repositories in one place, with a one-click switch to the expected context. Desktop reads the same profiles, contexts, and workspace rules as the CLI; enforcement at launch still comes from the shell hook. Credentials stay in each tool’s local storage, as described in the security model.

Verify the result

Run aisw context use personal, change into the bound repository, and start an agent. Strict mode should refuse with the output above; warn mode should print the warning and start the agent. Then run aisw context use work, confirm aisw workspace status reports match, and start the agent again. It should launch with no message.