brindle 0.3.0__tar.gz → 0.3.1__tar.gz

{brindle-0.3.0 → brindle-0.3.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: brindle
-Version: 0.3.0
+Version: 0.3.1
 Summary: Run coding agents in parallel, each on its own git branch, with a supervisor that delegates, reviews, and merges
 Project-URL: Homepage, https://pawdelta.com/brindle/
 Project-URL: Documentation, https://pawdelta.com/brindle/docs/recommended-use
@@ -89,7 +89,7 @@ uv tool install --editable ~/Projects/brindle   # or from a local checkout
 brindle drives Claude Code, so you need that too (`npm install -g @anthropic-ai/claude-code`).
 
 `brindle --version` prints the installed version; the tmux status bar of every brindle
-session shows it too (`brindle 0.3.0`). A session started before an upgrade keeps
+session shows it too (`brindle 0.3.1`). A session started before an upgrade keeps
 running the old code, and shows the old number, until you restart it.
 
 ## Quick start
@@ -363,6 +363,7 @@ your own status line prints, so what you see doesn't change.
 | `brindle learning` | whether brindle Pro's hosted learning is on for this repo, and if not, why (nothing is learned on your machine) |
 | `brindle learning seed` | Pro: sends this repo's finished routing history to the hosted learner once, so it starts with what this machine has seen. Only the usual coarse record fields leave (kind/size one-hots, counters, HMAC keys), never task text or paths. A second run sends nothing new; decisions already sent live are skipped |
 | `brindle account [login\|logout\|status\|upgrade\|portal\|seats\|org]` | paid features: bare `brindle account` shows what your plan has and how to get the rest (see "brindle Pro and Team" below) |
+| `brindle login` | the same as `brindle account login`; when your org's policy has an `agent_setup` block it also signs you in to the Claude and Codex route the company chose (AWS SSO profile, `gcloud`, `az`, `claude auth login`, `codex login`), stores the Claude Code environment for brindle's panes in `~/.brindle/config.json`, and checks the pinned models. `brindle doctor --fix` does the same |
 | `brindle audit verify\|export\|pubkey\|ship\|prune` | the local tamper-evident audit log, and shipping it to your SIEM (brindle Enterprise; see "Audit log" below) |
 | `brindle watch [--all] [--once]` | the dashboard on its own (the same view as the sidebar): enter attaches, `p` peeks, `x` closes |
 | `brindle sidebar` | bring this session's sidebar into the tmux session you're in (also `Ctrl-b S` in a window without one); restarts it if it was closed |
@@ -762,6 +763,7 @@ workflow.
 
 ```sh
 brindle account            # paid features: what you have, how to use them, how to get the rest
+brindle login              # the same as `brindle account login`; also applies your org's agent_setup (company agent sign-in)
 brindle account login      # opens your browser to sign in (--device: enter a code instead, e.g. over SSH); brindle checks the plan offline from then on
 brindle account status     # your plan, features, hosted learning on or off, when the entitlement expires
 brindle account savings    # what hosted learning's picks gained in this repo, this month and last: estimates, from this machine's records only
@@ -778,6 +780,51 @@ brindle account org member policy-role <member> <role|none>   # give a member a
 brindle account org company [link <org_id> | unlink]          # link orgs you own into one company; learning is pooled only within it
 ```
 
+**Sign-in loss pauses agents.** While agents run, brindle checks every 30 s that
+Claude and Codex are still signed in (`claude auth status` or the cloud route's
+identity, re-checked only when its credentials change; `codex login status`;
+Antigravity can't be checked). If one is signed out, its running agents pause
+with their worktrees, commits and conversations kept, and the supervisor and
+your session are told; a timeout or missing CLI never pauses, it warns once.
+A wrong company identity pauses them only when the org policy enforces it
+(Enterprise); otherwise it warns once. While it enforces, Claude agents run
+on exactly the route brindle checked: a profile's env lines can't change the
+backend, account, key or proxy, and other cloud and Claude credential variables
+(`ANTHROPIC_*`, `AWS_*`, `GOOGLE_*`, `CLOUDSDK_*`, `AZURE_*`, ...) in your
+environment or `brindle keys` are left out of their panes, so those agents
+can't use your own AWS, Google Cloud or Azure access in their shell either.
+Claude Code's own settings files can still set variables inside it; to rule
+that out too, use Claude Code's managed settings. After `brindle login`,
+`brindle doctor --fix` or the CLI's own login, the agents brindle paused resume
+into their conversations, but only as the account they started under: if
+someone else is signed in (a personal login, say) they stay paused until the
+original account is back. Your own chat session is never paused, only the
+workers. A cloud sign-in is re-checked only when its credential files or
+variables change, so a token that expires silently isn't noticed until then.
+`brindle doctor` lists agents paused for sign-in.
+
+**Sessions stay with their identity.** Each Claude agent records the identity it
+launched under (Claude org, AWS account and role, GCP project, Azure
+subscription; ids only, never tokens). While a different identity is signed in,
+that agent is locked: brindle refuses to resume it (`brindle continue`), rewind
+it, message or hand off to it, start a new agent in its worktree (including
+naming its branch for a new worker), or `peek` at it, with "This session
+belongs to <org/account>; sign in as it to continue (`brindle login`)".
+`brindle ls`, `watch`, the sidebar, `list_agents` and `agent_turns` show it as
+`locked: <org/account>` without its conversation (usage, last activity, turn
+summaries), and `depends_on` and `merge_workspace` won't pull its branch into a
+session under another identity. Agents with no recorded identity (started before
+this, or without a company setup) are unaffected, and so is everything while the
+current identity can't be told (signed out, CLI missing).
+
+This is a guard inside brindle, not a sandbox: on one OS user account the
+worktrees, transcripts and credential files stay readable outside brindle (a
+shell, another tool). Real separation needs a separate OS user or your
+company's device management. Codex and Antigravity can't be told apart by
+account (brindle only sees "signed in"), so their sessions are paused on
+sign-out but can't be locked to one account; isolation applies to Claude routes
+(subscription, Bedrock, Vertex, Foundry).
+
 ### Several repos in one session (brindle Pro)
 
 A session can work across several repos. Attach another local repo you own
@@ -1258,7 +1305,7 @@ it's signed in without a plan that includes it, is reported to its supervisor.
 | Provider | Key login (environment variables) |
 |---|---|
 | `claude` | yes: `ANTHROPIC_API_KEY`, `ANTHROPIC_AUTH_TOKEN`, `CLAUDE_CODE_OAUTH_TOKEN`, or Bedrock/Vertex/Foundry (`CLAUDE_CODE_USE_BEDROCK`, `CLAUDE_CODE_USE_VERTEX`, `CLAUDE_CODE_USE_FOUNDRY`) |
-| `codex` | yes: `OPENAI_API_KEY`, `CODEX_API_KEY` |
+| `codex` | yes: `OPENAI_API_KEY`, `CODEX_API_KEY`. With Codex signed in with ChatGPT (checked on Codex CLI 0.162.0): interactive `codex`, which brindle runs in agent panes, ignores both keys and uses the ChatGPT plan, and only `codex login --with-api-key` switches it to a key; headless `codex exec` (Brindle-CI) bills `CODEX_API_KEY` over the login and ignores `OPENAI_API_KEY`. `brindle doctor` and `brindle keys set` say so, and `auth: api_key` on an interactive Codex profile is refused under a ChatGPT login (run `codex login --with-api-key`, or use `auth: subscription`) |
 | `antigravity` | `GEMINI_API_KEY`, only with `"modelProvider": "gemini"` in `agy`'s `settings.json` (see [Google Antigravity](#google-antigravity)); otherwise `agy`'s own browser sign-in |
 
 Workers that run unattended should use key login where the CLI supports it.
@@ -1666,6 +1713,30 @@ marks the agent idle and delivers any queued message. Codex has no Stop hook, so
 an autopilot supervisor on Codex that turn end is also where brindle tells it to keep
 going, with the same limit on reminders as Claude Code.
 
+### Using your company's access
+
+Two ways to run brindle's agents on your company's Claude (Bedrock, Vertex,
+Foundry, a Team or Enterprise plan) and Codex, without handling keys:
+
+- **Your org sets it up (brindle Team).** When your org's policy has an
+  `agent_setup` block, `brindle login` (and `brindle doctor --fix`) signs you
+  in to the route the company chose and `brindle doctor` shows which identity
+  each agent uses. It always wins over anything below.
+- **You set it up yourself (any plan).** When your org has no `agent_setup`,
+  `brindle login` looks, read-only, at what this machine is already signed in
+  to: Claude Code's managed settings (if your IT configures Claude Code,
+  brindle just uses it), `claude auth status`, AWS SSO profiles in
+  `~/.aws/config`, the active `gcloud` project, the active `az` subscription
+  and `codex login status`. It never reads tokens or credential files. It
+  proposes what it found ("Use Bedrock (AWS 1234…, role Dev, us-east-1)?");
+  the default is no, and with no terminal it is always no. A yes is saved as
+  `"agent_setup"` in `~/.brindle/config.json`, in the same format as the org
+  policy's (`enforce` is never applied to it), and `brindle doctor` labels it
+  as self-serve and says who is billed.
+
+You must be authorized to use any company credentials you connect: brindle only
+signs in with the access you already have, it doesn't grant any.
+
 ## Google Antigravity
 
 brindle runs Google Antigravity's terminal agent, `agy`, as well as Claude Code and

{brindle-0.3.0 → brindle-0.3.1}/README.md

@@ -59,7 +59,7 @@ uv tool install --editable ~/Projects/brindle   # or from a local checkout
 brindle drives Claude Code, so you need that too (`npm install -g @anthropic-ai/claude-code`).
 
 `brindle --version` prints the installed version; the tmux status bar of every brindle
-session shows it too (`brindle 0.3.0`). A session started before an upgrade keeps
+session shows it too (`brindle 0.3.1`). A session started before an upgrade keeps
 running the old code, and shows the old number, until you restart it.
 
 ## Quick start
@@ -333,6 +333,7 @@ your own status line prints, so what you see doesn't change.
 | `brindle learning` | whether brindle Pro's hosted learning is on for this repo, and if not, why (nothing is learned on your machine) |
 | `brindle learning seed` | Pro: sends this repo's finished routing history to the hosted learner once, so it starts with what this machine has seen. Only the usual coarse record fields leave (kind/size one-hots, counters, HMAC keys), never task text or paths. A second run sends nothing new; decisions already sent live are skipped |
 | `brindle account [login\|logout\|status\|upgrade\|portal\|seats\|org]` | paid features: bare `brindle account` shows what your plan has and how to get the rest (see "brindle Pro and Team" below) |
+| `brindle login` | the same as `brindle account login`; when your org's policy has an `agent_setup` block it also signs you in to the Claude and Codex route the company chose (AWS SSO profile, `gcloud`, `az`, `claude auth login`, `codex login`), stores the Claude Code environment for brindle's panes in `~/.brindle/config.json`, and checks the pinned models. `brindle doctor --fix` does the same |
 | `brindle audit verify\|export\|pubkey\|ship\|prune` | the local tamper-evident audit log, and shipping it to your SIEM (brindle Enterprise; see "Audit log" below) |
 | `brindle watch [--all] [--once]` | the dashboard on its own (the same view as the sidebar): enter attaches, `p` peeks, `x` closes |
 | `brindle sidebar` | bring this session's sidebar into the tmux session you're in (also `Ctrl-b S` in a window without one); restarts it if it was closed |
@@ -732,6 +733,7 @@ workflow.
 
 ```sh
 brindle account            # paid features: what you have, how to use them, how to get the rest
+brindle login              # the same as `brindle account login`; also applies your org's agent_setup (company agent sign-in)
 brindle account login      # opens your browser to sign in (--device: enter a code instead, e.g. over SSH); brindle checks the plan offline from then on
 brindle account status     # your plan, features, hosted learning on or off, when the entitlement expires
 brindle account savings    # what hosted learning's picks gained in this repo, this month and last: estimates, from this machine's records only
@@ -748,6 +750,51 @@ brindle account org member policy-role <member> <role|none>   # give a member a
 brindle account org company [link <org_id> | unlink]          # link orgs you own into one company; learning is pooled only within it
 ```
 
+**Sign-in loss pauses agents.** While agents run, brindle checks every 30 s that
+Claude and Codex are still signed in (`claude auth status` or the cloud route's
+identity, re-checked only when its credentials change; `codex login status`;
+Antigravity can't be checked). If one is signed out, its running agents pause
+with their worktrees, commits and conversations kept, and the supervisor and
+your session are told; a timeout or missing CLI never pauses, it warns once.
+A wrong company identity pauses them only when the org policy enforces it
+(Enterprise); otherwise it warns once. While it enforces, Claude agents run
+on exactly the route brindle checked: a profile's env lines can't change the
+backend, account, key or proxy, and other cloud and Claude credential variables
+(`ANTHROPIC_*`, `AWS_*`, `GOOGLE_*`, `CLOUDSDK_*`, `AZURE_*`, ...) in your
+environment or `brindle keys` are left out of their panes, so those agents
+can't use your own AWS, Google Cloud or Azure access in their shell either.
+Claude Code's own settings files can still set variables inside it; to rule
+that out too, use Claude Code's managed settings. After `brindle login`,
+`brindle doctor --fix` or the CLI's own login, the agents brindle paused resume
+into their conversations, but only as the account they started under: if
+someone else is signed in (a personal login, say) they stay paused until the
+original account is back. Your own chat session is never paused, only the
+workers. A cloud sign-in is re-checked only when its credential files or
+variables change, so a token that expires silently isn't noticed until then.
+`brindle doctor` lists agents paused for sign-in.
+
+**Sessions stay with their identity.** Each Claude agent records the identity it
+launched under (Claude org, AWS account and role, GCP project, Azure
+subscription; ids only, never tokens). While a different identity is signed in,
+that agent is locked: brindle refuses to resume it (`brindle continue`), rewind
+it, message or hand off to it, start a new agent in its worktree (including
+naming its branch for a new worker), or `peek` at it, with "This session
+belongs to <org/account>; sign in as it to continue (`brindle login`)".
+`brindle ls`, `watch`, the sidebar, `list_agents` and `agent_turns` show it as
+`locked: <org/account>` without its conversation (usage, last activity, turn
+summaries), and `depends_on` and `merge_workspace` won't pull its branch into a
+session under another identity. Agents with no recorded identity (started before
+this, or without a company setup) are unaffected, and so is everything while the
+current identity can't be told (signed out, CLI missing).
+
+This is a guard inside brindle, not a sandbox: on one OS user account the
+worktrees, transcripts and credential files stay readable outside brindle (a
+shell, another tool). Real separation needs a separate OS user or your
+company's device management. Codex and Antigravity can't be told apart by
+account (brindle only sees "signed in"), so their sessions are paused on
+sign-out but can't be locked to one account; isolation applies to Claude routes
+(subscription, Bedrock, Vertex, Foundry).
+
 ### Several repos in one session (brindle Pro)
 
 A session can work across several repos. Attach another local repo you own
@@ -1228,7 +1275,7 @@ it's signed in without a plan that includes it, is reported to its supervisor.
 | Provider | Key login (environment variables) |
 |---|---|
 | `claude` | yes: `ANTHROPIC_API_KEY`, `ANTHROPIC_AUTH_TOKEN`, `CLAUDE_CODE_OAUTH_TOKEN`, or Bedrock/Vertex/Foundry (`CLAUDE_CODE_USE_BEDROCK`, `CLAUDE_CODE_USE_VERTEX`, `CLAUDE_CODE_USE_FOUNDRY`) |
-| `codex` | yes: `OPENAI_API_KEY`, `CODEX_API_KEY` |
+| `codex` | yes: `OPENAI_API_KEY`, `CODEX_API_KEY`. With Codex signed in with ChatGPT (checked on Codex CLI 0.162.0): interactive `codex`, which brindle runs in agent panes, ignores both keys and uses the ChatGPT plan, and only `codex login --with-api-key` switches it to a key; headless `codex exec` (Brindle-CI) bills `CODEX_API_KEY` over the login and ignores `OPENAI_API_KEY`. `brindle doctor` and `brindle keys set` say so, and `auth: api_key` on an interactive Codex profile is refused under a ChatGPT login (run `codex login --with-api-key`, or use `auth: subscription`) |
 | `antigravity` | `GEMINI_API_KEY`, only with `"modelProvider": "gemini"` in `agy`'s `settings.json` (see [Google Antigravity](#google-antigravity)); otherwise `agy`'s own browser sign-in |
 
 Workers that run unattended should use key login where the CLI supports it.
@@ -1636,6 +1683,30 @@ marks the agent idle and delivers any queued message. Codex has no Stop hook, so
 an autopilot supervisor on Codex that turn end is also where brindle tells it to keep
 going, with the same limit on reminders as Claude Code.
 
+### Using your company's access
+
+Two ways to run brindle's agents on your company's Claude (Bedrock, Vertex,
+Foundry, a Team or Enterprise plan) and Codex, without handling keys:
+
+- **Your org sets it up (brindle Team).** When your org's policy has an
+  `agent_setup` block, `brindle login` (and `brindle doctor --fix`) signs you
+  in to the route the company chose and `brindle doctor` shows which identity
+  each agent uses. It always wins over anything below.
+- **You set it up yourself (any plan).** When your org has no `agent_setup`,
+  `brindle login` looks, read-only, at what this machine is already signed in
+  to: Claude Code's managed settings (if your IT configures Claude Code,
+  brindle just uses it), `claude auth status`, AWS SSO profiles in
+  `~/.aws/config`, the active `gcloud` project, the active `az` subscription
+  and `codex login status`. It never reads tokens or credential files. It
+  proposes what it found ("Use Bedrock (AWS 1234…, role Dev, us-east-1)?");
+  the default is no, and with no terminal it is always no. A yes is saved as
+  `"agent_setup"` in `~/.brindle/config.json`, in the same format as the org
+  policy's (`enforce` is never applied to it), and `brindle doctor` labels it
+  as self-serve and says who is billed.
+
+You must be authorized to use any company credentials you connect: brindle only
+signs in with the access you already have, it doesn't grant any.
+
 ## Google Antigravity
 
 brindle runs Google Antigravity's terminal agent, `agy`, as well as Claude Code and

{brindle-0.3.0 → brindle-0.3.1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "brindle"
-version = "0.3.0"
+version = "0.3.1"
 description = "Run coding agents in parallel, each on its own git branch, with a supervisor that delegates, reviews, and merges"
 readme = "README.md"
 requires-python = ">=3.11"

{brindle-0.3.0 → brindle-0.3.1}/src/brindle/agents.py

@@ -20,7 +20,7 @@ import sys
 import time
 import uuid
 
-from brindle import git, keystore, pane_auth, providers, secrets, tmux, workspaces
+from brindle import company_identity, company_login, git, keystore, pane_auth, providers, secrets, tmux, workspaces
 from brindle.config import RepoConfig
 from brindle.db import DB, Agent, Workspace
 from brindle.profiles import load_profile, missing_add_dirs
@@ -183,7 +183,19 @@ def agent_env(ws: Workspace, agent_id: str, agent: Agent | None = None,
         # Claude Code's own managed settings (apiKeyHelper, a managed env) pick
         # the credential and backend: brindle adds no provider_config env there.
         org = agent.provider == "claude" and providers.claude_org_managed()
-        env = {**profile_env, **({} if org else managed_models.agent_env(m, agent.provider)), **env}
+        # The company's Claude Code env (`brindle login`): the lowest layer, so a
+        # profile's env lines and the org's managed provider both beat it; none
+        # at all under Claude Code's managed settings (stored_env).
+        company = {} if agent.provider != "claude" else company_login.stored_env()
+        managed_env = {} if org else managed_models.agent_env(m, agent.provider)
+        enforced = None if agent.provider != "claude" or org else company_identity.enforced_route_env()
+        if enforced is None:
+            env = {**company, **profile_env, **managed_env, **env}
+        else:
+            # An enforced company identity (Enterprise): the pane runs on the route
+            # launch_problem checked, whatever a profile's env lines say.
+            profile_env = {k: v for k, v in profile_env.items() if company_identity.profile_may_set(k)}
+            env = {**profile_env, **managed_env, **enforced, **env}
     if agent is not None and preload_tools(agent, ws):
         # Claude Code defers MCP tools and loads them on demand, which costs a
         # worker an extra round trip at the moment it's told to report (and
@@ -262,7 +274,9 @@ def spawn(
     finish line run it as a Claude Code ``/goal``. With ``autopilot``, the
     agent is a session root that drives toward a goal (see brindle.autopilot)."""
     from brindle import autopilot as pilot
+    from brindle import identity_lock
 
+    identity_lock.ensure_workspace(db, ws)   # no new agent in another identity's worktree
     profile = load_profile(profile_name, ws.repo_root)
     provider = get_provider(provider_name or profile.provider)
     agent_id = new_id()
@@ -440,6 +454,12 @@ def _open_window(db: DB, agent: Agent, ws: Workspace, name: str, argv: list[str]
         org_env = managed_models.org_key_env(m, agent.provider)
     except managed_models.ManagedUnavailable as e:
         raise AgentError(f"managed models: {e}") from None
+    # An enforced company identity: also every account picker the tmux server
+    # would hand the pane or `brindle keys` holds for it (pane_auth covers this process's).
+    route = None if agent.provider != "claude" or org_managed else company_identity.enforced_route_env()
+    if route is not None:
+        extra = company_identity.enforced_deny(route, tmux.inherited_names(ws.tmux_session), credentials)
+        deny = (*deny, *(n for n in extra if n not in deny))
     # Claude Code's managed settings supply the credential: no stored Claude key.
     no_stored = set(deny) | (set(providers._ENV_AUTH["claude"]) if org_managed else set())
     env = {**keystore.pane_keys(credentials - no_stored, {**env, **org_env}), **env, **org_env}
@@ -612,6 +632,14 @@ def _launch(db: DB, agent: Agent, ws: Workspace, *, prompt: str | None,
         db.set_status(agent.id, status)
         agent.status = status
         return
+    # An org that enforces its company sign-in (Enterprise) refuses a
+    # different identity; one that can't be told never blocks.
+    why = company_identity.launch_problem(provider.name)
+    if why:
+        raise AgentError(why)
+    from brindle import signin_pause
+
+    signin_pause.record_launch(agent)   # who it runs as, so a resume never crosses accounts
     # What the agent will run with: the managed provider's variables, and
     # no personal keys (blank, so the launcher's own copy doesn't count).
     from brindle.pro import managed_models
@@ -906,10 +934,14 @@ def resume(db: DB, root_id: str, *, watch_pane: bool = True,
     restart in their own workspaces. Claude Code picks up its previous
     conversation (--resume); other CLIs restart on their original task.
     With ``only``, just those agents (if paused) restart."""
+    from brindle import identity_lock
+
+    candidates = [a for a in tree(db, root_id)
+                  if a.status == "paused" and (only is None or a.id in only)]
+    for a in candidates:   # all or nothing: a session never half-resumes under another identity
+        identity_lock.ensure(a)
     resumed = []
-    for a in tree(db, root_id):
-        if a.status != "paused" or (only is not None and a.id not in only):
-            continue
+    for a in candidates:
         ws = db.get_workspace(a.workspace_id)
         if ws is None or not os.path.isdir(ws.path):
             continue
@@ -1138,7 +1170,10 @@ def send_message(db: DB, to_id: str, body: str, sender_id: str | None = None,
     """Deliver now if the agent is idle; otherwise queue until it is.
     Returns ``"delivered"`` or ``"queued"``. ``person`` marks a message from
     the person running brindle, which is always pushed."""
+    from brindle import identity_lock
+
     agent = get(db, to_id)
+    identity_lock.ensure(agent)
     if not person and runs_process(agent) and is_alive(agent) and pulls_messages(db, agent):
         # Keep the message unread and deliver only a notice, once for everything unread.
         db.enqueue_held(agent.id, format_message(db, body, sender_id), sender_id)
@@ -1648,6 +1683,13 @@ def delegate(
         raise AgentError(str(e)) from e
     if plan_first is None:
         plan_first = load_repo_config(caller_ws.repo_root).plan_first
+    from brindle import identity_lock
+
+    identity_lock.ensure_workspace(db, caller_ws)
+    if isolate and branch:   # naming a branch must not reuse another identity's worktree
+        for other in db.find_workspaces(caller_ws.repo_root):
+            if other.branch == branch:
+                identity_lock.ensure_workspace(db, other)
     if isolate:
         caller_ws = workspaces.refresh_branch(db, caller_ws)
         # merge_into applies to the supervisor's workers; a worker's own

{brindle-0.3.0 → brindle-0.3.1}/src/brindle/cli.py

@@ -13,7 +13,7 @@ from typing import Optional
 
 import typer
 
-from brindle import agents, git, tmux, view, workspaces
+from brindle import agents, git, identity_lock, tmux, view, workspaces
 from brindle import history as history_mod
 from brindle import keys_cmds, repo_cmds
 from brindle.usage import format_tokens
@@ -792,7 +792,7 @@ def autopilot_cmd(
 
 @app.command()
 def doctor(
-    fix: bool = typer.Option(False, "--fix", help="Offer to let Claude Code use an exported ANTHROPIC_API_KEY without asking."),
+    fix: bool = typer.Option(False, "--fix", help="Offer to let Claude Code use an exported ANTHROPIC_API_KEY without asking, and agy a GEMINI_API_KEY (modelProvider \"gemini\")."),
 ) -> None:
     """Check that brindle has what it needs, and say what to do about anything missing.
 
@@ -1655,6 +1655,17 @@ def learning_seed() -> None:
                                "help_option_names": []})   # --help is the plugin's: it lists every subcommand
 def account(ctx: typer.Context) -> None:
     """brindle Pro/Team: paid features, login, upgrade, billing, orgs. Bare `brindle account` shows what you have."""
+    _run_account(list(ctx.args))
+
+
+@app.command("login", context_settings={"allow_extra_args": True, "ignore_unknown_options": True,
+                                         "help_option_names": []})
+def login(ctx: typer.Context) -> None:
+    """Log in to brindle and set up your company's agents: the same as `brindle account login`."""
+    _run_account(["login", *ctx.args])
+
+
+def _run_account(args: list[str]) -> None:
     from brindle import account as account_mod
     from brindle.config import load_repo_config
 
@@ -1668,7 +1679,7 @@ def account(ctx: typer.Context) -> None:
         from brindle.config import RepoConfig
 
         cfg = RepoConfig()
-    raise typer.Exit(account_mod.run(cfg, repo_root, list(ctx.args), echo=typer.echo))
+    raise typer.Exit(account_mod.run(cfg, repo_root, args, echo=typer.echo))
 
 
 # -- brindle audit (brindle Enterprise: the local tamper-evident audit chain) ---------------------
@@ -2141,6 +2152,7 @@ def agent_peek(agent_id: str, lines: int = typer.Option(40, "--lines", "-n")) ->
     """Print the last lines of an agent's terminal."""
     db = DB()
     a = _run(agents.get, db, agent_id)
+    _run(identity_lock.ensure, a)
     if not a.tmux_window:
         typer.secho(f"{a.id} has no terminal (it runs as its supervisor's own subagent)"
                     if not agents.runs_process(a) else f"{a.id} has no terminal", fg="red", err=True)
@@ -2158,6 +2170,11 @@ def agent_turns(agent_id: str) -> None:
     ws = db.get_workspace(a.workspace_id)
     if ws is None:
         _fail(f"{a.id}'s workspace is gone")
+    from brindle import identity_lock
+
+    who = identity_lock.locked_by(a.id)
+    if who:
+        _fail(f"{a.id} is locked: {who}. {identity_lock.message(who)}.")
     typer.echo(rewind.format_turns(ws.repo_root, a.id))