brindle 0.3.0__tar.gz → 0.3.2__tar.gz

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: brindle
-Version: 0.3.0
+Version: 0.3.2
 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.2`). 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 |
@@ -538,6 +539,7 @@ Autopilot, merge gates and cleanup:
 | `merge_into` | none | branch that worker branches are cut from and merge into, whatever branch the supervisor is on |
 | `auto_merge_default_branch` | `false` | let the pipeline merge into the repo's default branch (origin HEAD, else `main`/`master`) on its own; by default it sends a "needs you" message instead, and you run `merge_workspace` yourself (manual merges are never gated) |
 | `permission_policy` | `"off"` | `"on"`: brindle answers Claude Code workers' permission prompts from its rules (see "Permission policy" below); off, the prompts behave as they always did |
+| `agy_approvals` | `"prompt"` | `"brindle"`: with the policy on, Antigravity workers run without approval prompts and brindle's hook allows or denies every call (see "Antigravity" under "Permission policy") |
 | `rules` | `[]` | standing rules for the supervisor, e.g. `["Fix review findings without asking", "Validate options before offering them"]`; added to every supervisor's brief. Rules in `~/.brindle/config.json`, the repo's config and `config.local.json` are all kept, so a team's rules and your own add up |
 | `plan_first` | `false` | workers propose a plan (`submit_plan`) and wait for `approve_plan` before editing |
 | `overlap` | `"block"` | a task whose `files` overlap a running task's is refused (`"warn"` starts it with a warning) |
@@ -725,6 +727,21 @@ does it by hand. To undo, turn `permission_policy` off and run `sync-agy`: brind
 removes exactly its own entries. brindle doesn't learn from agy approvals (its
 hook runs for every tool call, so a tool running doesn't mean you approved it).
 
+With `"agy_approvals": "brindle"` (and the policy on), brindle's hook is the
+only gate instead: agy workers start with `--dangerously-skip-permissions`,
+under which agy still honors a hook's deny, and the hook runs on every tool,
+subagents' calls included. It allows what a rule allows (a repo's checks
+included), the shell commands in the profile's `allowed_tools` (what a Claude
+Code worker on it runs without asking), files inside the workspace given as one
+absolute path (writes under `.agents/`, `.git/` and
+`.brindle/` only by a rule, since those hold the hook, git's hooks and the
+repo's checks), brindle's own tools and agy's tools that act only on the
+conversation, and denies everything else, telling the agent to
+ask its supervisor; you allow it with `brindle permissions allow`. Any failure
+in the hook is a deny, and a tool brindle doesn't know is denied. Nobody can
+approve a prompt in the agent's pane in this mode. The default, `"prompt"`,
+leaves agy asking as described above.
+
 ## brindle Pro and Team
 
 brindle is complete on its own. brindle Pro adds hosted learning (which profile
@@ -762,6 +779,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 +796,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 +1321,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 +1729,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.2}/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.2`). 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 |
@@ -508,6 +509,7 @@ Autopilot, merge gates and cleanup:
 | `merge_into` | none | branch that worker branches are cut from and merge into, whatever branch the supervisor is on |
 | `auto_merge_default_branch` | `false` | let the pipeline merge into the repo's default branch (origin HEAD, else `main`/`master`) on its own; by default it sends a "needs you" message instead, and you run `merge_workspace` yourself (manual merges are never gated) |
 | `permission_policy` | `"off"` | `"on"`: brindle answers Claude Code workers' permission prompts from its rules (see "Permission policy" below); off, the prompts behave as they always did |
+| `agy_approvals` | `"prompt"` | `"brindle"`: with the policy on, Antigravity workers run without approval prompts and brindle's hook allows or denies every call (see "Antigravity" under "Permission policy") |
 | `rules` | `[]` | standing rules for the supervisor, e.g. `["Fix review findings without asking", "Validate options before offering them"]`; added to every supervisor's brief. Rules in `~/.brindle/config.json`, the repo's config and `config.local.json` are all kept, so a team's rules and your own add up |
 | `plan_first` | `false` | workers propose a plan (`submit_plan`) and wait for `approve_plan` before editing |
 | `overlap` | `"block"` | a task whose `files` overlap a running task's is refused (`"warn"` starts it with a warning) |
@@ -695,6 +697,21 @@ does it by hand. To undo, turn `permission_policy` off and run `sync-agy`: brind
 removes exactly its own entries. brindle doesn't learn from agy approvals (its
 hook runs for every tool call, so a tool running doesn't mean you approved it).
 
+With `"agy_approvals": "brindle"` (and the policy on), brindle's hook is the
+only gate instead: agy workers start with `--dangerously-skip-permissions`,
+under which agy still honors a hook's deny, and the hook runs on every tool,
+subagents' calls included. It allows what a rule allows (a repo's checks
+included), the shell commands in the profile's `allowed_tools` (what a Claude
+Code worker on it runs without asking), files inside the workspace given as one
+absolute path (writes under `.agents/`, `.git/` and
+`.brindle/` only by a rule, since those hold the hook, git's hooks and the
+repo's checks), brindle's own tools and agy's tools that act only on the
+conversation, and denies everything else, telling the agent to
+ask its supervisor; you allow it with `brindle permissions allow`. Any failure
+in the hook is a deny, and a tool brindle doesn't know is denied. Nobody can
+approve a prompt in the agent's pane in this mode. The default, `"prompt"`,
+leaves agy asking as described above.
+
 ## brindle Pro and Team
 
 brindle is complete on its own. brindle Pro adds hosted learning (which profile
@@ -732,6 +749,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 +766,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 +1291,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 +1699,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.2}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "brindle"
-version = "0.3.0"
+version = "0.3.2"
 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.2}/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
@@ -1082,7 +1114,7 @@ def format_message(db: DB, body: str, sender_id: str | None) -> str:
         return body
     sender = db.get_agent(sender_id)
     who = f"{sender.profile} agent {sender_id}" if sender else f"agent {sender_id}"
-    return f"[Message from {who}. Reply with the brindle send_message tool, to_agent_id={sender_id}]\n\n{body}"
+    return f"<details><summary>Message from {who}</summary>\n\nReply with the brindle send_message tool, to_agent_id={sender_id}\n\n{body}\n</details>"
 
 
 def message_lead(db: DB, agent: Agent, sender_id: str | None) -> str | None:
@@ -1129,8 +1161,8 @@ def render_unread(db: DB, messages: list) -> str:
         if m.sender_id:
             parts.append(m.body)  # stored through format_message: sender and reply hint
         else:
-            parts.append(f"[Message from brindle]\n\n{m.body}")
-    return "\n\n---\n\n".join(parts)
+            parts.append(f"<details><summary>Message from brindle</summary>\n\n{m.body}\n</details>")
+    return "\n\n".join(parts)
 
 
 def send_message(db: DB, to_id: str, body: str, sender_id: str | None = None,
@@ -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)
@@ -1168,6 +1203,9 @@ def _send_message(db: DB, agent: Agent, body: str, sender_id: str | None) -> str
         raise AgentError(f"agent {agent.id} is not running")
     provider = get_provider(agent.provider)
     text = format_message(db, body, sender_id)
+    if agent.provider == "antigravity":
+        from brindle.antigravity import format_delivered_message
+        text = format_delivered_message(text)
     if agent.headless:
         # Its runner starts the next turn with this, or the Stop hook hands it
         # over if a turn is still running.
@@ -1648,6 +1686,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