brindle 0.2.1__tar.gz → 0.3.1__tar.gz

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: brindle
-Version: 0.2.1
+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.2.1`). 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
@@ -350,6 +350,7 @@ your own status line prints, so what you see doesn't change.
 | `brindle transfer [REPO] [--from SESSION] [-b BRANCH]` | move a scratch session's work into a real repo |
 | `brindle ls [--all]` | workspaces and agents |
 | `brindle repo add PATH [--name ALIAS] / rm ALIAS / ls` | attach other local repos to the current session so workers can go there (brindle Pro; see "Several repos in one session") |
+| `brindle keys set/unset/list [NAME]` | store model API keys (e.g. `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`) once in the OS keychain (or a 0600 file); every agent pane gets the ones its provider reads, unless you already export it. `set` reads the value from a hidden prompt or stdin, `list` shows names and the last 4 characters. `CLAUDE_CODE_OAUTH_TOKEN` (a Claude subscription token) is never stored |
 | `brindle history [--limit N] [--kind K] [--all]` | durable log of worker results, reviews, merges and milestone checks |
 | `brindle cost [--days N] [--all]` | dollar spend at list prices over the last 30 days, by model |
 | `brindle cost report [--days N] [--all]` | Pro: spend by day, profile and goal, cost per merged branch, review pass rate per worker profile |
@@ -361,7 +362,8 @@ your own status line prints, so what you see doesn't change.
 | `brindle cost estimate [--tasks N] [--weight W] [--profile P] [--reviewer R]` | what the current goal (or N tasks) is likely to cost, as a range from this repo's history (median to p80 of past worker and review runs), plus a cheaper alternative with a different reviewer; says "low confidence" when there's too little history. Also added to `set_goal` and `assign` replies (brindle Pro) |
 | `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\|org]` | paid features: bare `brindle account` shows what your plan has and how to get the rest (see "brindle Pro and Team" below) |
+| `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 |
@@ -526,6 +528,7 @@ Autopilot, merge gates and cleanup:
 | `max_agents` | `4` | workers running at once per session (`0`: no cap) |
 | `check_timeout` | `900` | seconds each check may take |
 | `check_concurrency` | `2` | check runs at once on this machine, across branches; the rest wait their turn (`0`: no cap). A run far past its last duration is reported to the supervisor |
+| `fable_escalation` | on, unless the worker runs on a cloud account (Bedrock, Vertex or Foundry) | retry a failed heavy task once on `developer-heavy` (Fable) before handing it to you; `true` turns it on for a cloud account, `false` off |
 | `usage_limit` | `90` | autopilot stops pushing on at this % of your Claude usage limit |
 | `limit_cooldown_minutes` | `300` for Antigravity | how long a provider that hit its limit counts as unavailable |
 | `graphify` | if the graph is there | point agents at the repo's [graphify](https://github.com/safishamsi/graphify) code map (`false` turns it off) |
@@ -589,9 +592,9 @@ keep theirs):
 ```json
 {
   "routing": {
-    "light":  ["developer", "developer-codex", "developer-local"],
+    "light":  ["developer-light", "developer", "developer-codex", "developer-local"],
     "medium": ["developer", "developer-codex", "developer-heavy"],
-    "heavy":  ["developer-heavy", "developer", "developer-codex"]
+    "heavy":  ["developer", "developer-heavy", "developer-codex"]
   }
 }
 ```
@@ -599,7 +602,9 @@ keep theirs):
 No tier prefers another provider for its own sake: all-Claude or all-Codex may
 be what works best for you, and that's for the learner to find out.
 
-`developer-codex` runs on Codex; `developer-heavy` on Claude Fable at high effort.
+`developer-light` runs on Claude Haiku at low effort; `developer` on your Claude
+Code default model; `developer-codex` on Codex; `developer-heavy` on Claude Fable
+at high effort.
 A profile is skipped when its CLI isn't installed (`claude`, `codex`, `agy`), the
 local model server isn't answering, or its provider is at your `usage_limit`. If
 hosted learning is on it chooses among the profiles left; otherwise the first
@@ -758,11 +763,14 @@ 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
 brindle account upgrade    # opens the checkout for brindle Pro (and prints its URL)
-brindle account portal     # opens the billing portal (invoices, seats, cancellation); --org ORG for a team org
+brindle account upgrade --enterprise [--trial] --seats N --org ORG   # brindle Enterprise for a team org; --trial: free trial, at most 10 seats
+brindle account portal     # opens the billing portal (invoices, payment method, cancellation); --org ORG for a team org
+brindle account seats N    # set a Team or Enterprise org's seat count (billing admin); --org ORG; Stripe prorates the change
 brindle account org list   # the orgs you belong to; `org use <id>` switches, `org policy` shows the current one
 brindle account org policy # the org's policy, its per-role overrides, and the policy that applies to you
 brindle account org profiles                                  # the org's shared profiles and rule packs, and which are pinned
@@ -772,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
@@ -825,6 +878,16 @@ entitlement.
 * `deny_personal_keys`: the personal model keys (`ANTHROPIC_API_KEY`,
   `OPENAI_API_KEY`, ...) are taken out of every agent pane, and a profile that
   sets one is refused.
+* An org-owned key: with `provider` `anthropic` (or `openai-compatible`), set
+  `key_env` to the name of a variable that holds the org's key (not a personal
+  one like `ANTHROPIC_API_KEY`), or `key_helper` to a command, as a list of
+  arguments, that prints the key (for example `["vault", "kv", "get",
+  "-field=key", "secret/anthropic"]`). brindle runs the helper on the person's
+  machine, without a shell and with a timeout, each time a worker starts, and
+  gives the key to that worker as `ANTHROPIC_API_KEY` (`OPENAI_API_KEY` for
+  Codex). It passes `deny_personal_keys`; a personal key doesn't. The key never
+  goes through brindle's servers. When the variable is missing or the helper
+  fails, the worker doesn't start.
 
 Two things to know when you turn on `deny_personal_keys`:
 
@@ -985,17 +1048,31 @@ workflows call these commands:
   commits the workflows on a `brindle/ci-setup` branch, then puts you back on
   the branch you started on and deletes the local setup branch, so `git pull`
   after merging the setup pull request is clean (commit or stash your changes
-  first: it refuses to start with uncommitted work).
+  first: it refuses to start with uncommitted work). With your own cloud
+  (`--credential bedrock|vertex|foundry`, keyless GitHub OIDC) it can read the
+  IDs from the deployment template's outputs instead of asking:
+  `--from-stack NAME [--region R]` (AWS CloudFormation), `--from-terraform DIR`
+  (Google) or `--from-deployment NAME -g RG` (Azure). They are defaults for
+  `--cloud-var`, which still overrides them, and every ID is format-checked. A
+  missing `aws`, `terraform` or `az` CLI or output is an error that names the
+  `--cloud-var` to pass instead. Vertex AI and Microsoft Foundry are in
+  **preview** (not yet verified end to end): `init` refuses them unless you pass
+  `--preview` or set `BRINDLE_CI_PREVIEW_CLOUDS=1`, and `doctor` marks them
+  `(preview)`. Bedrock is generally available.
 - `brindle ci doctor`: which provider CLIs and credential names a runner has, and
-  which providers CI may use on this repository.
+  which providers CI may use on this repository. `--models` also makes one tiny
+  call per pinned model and says why any is refused (a quota, a form not filled in).
 - `brindle ci start`: start a run for an issue, a goal text or a dispatched run,
   or a validation of a pull request.
 - `brindle ci run`: run what was started: the supervisor and the result upload,
   or the pull request's checks and reviews and the evidence upload.
 - `brindle ci report`: tell the service how the workflow's jobs ended.
 
-Credential names are reported, never values. On a repository owned by a GitHub
-organization, a provider signed in only with a personal subscription is not used.
+Credential names are reported, never values. CI uses API keys, cloud sign-ins
+(Bedrock, Vertex, Foundry) or identity federation only: a provider signed in
+only with a subscription (`CLAUDE_CODE_OAUTH_TOKEN`, a Codex ChatGPT login) is
+not used, on personal and organization repositories alike. Add an API key
+secret instead.
 
 Fix builds only fix the default branch's *required* status checks, and a new
 repository has none. When the default branch requires none, `brindle ci init`
@@ -1228,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.
@@ -1240,6 +1317,16 @@ needs no browser step. Put the key in your environment, or in a profile's
 `brindle doctor` names the variable each CLI gets, from your shell or from
 which profiles.
 
+A profile chooses between the two with `auth`:
+
+| `auth:` | What the worker signs in with |
+|---|---|
+| `auto` (default) | A key from your environment or `brindle keys` if there is one, else the CLI's own login. |
+| `subscription` | Always the CLI's own login: brindle strips that provider's API keys from the pane. |
+| `api_key` | Only a key: the worker refuses to start without one. |
+
+Your org's `deny_personal_keys` (Enterprise) still applies on top of `auth`.
+
 ### Cheap workers
 
 By default a Claude Code worker loads everything your own `claude` does: your
@@ -1626,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.2.1 → 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.2.1`). 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
@@ -320,6 +320,7 @@ your own status line prints, so what you see doesn't change.
 | `brindle transfer [REPO] [--from SESSION] [-b BRANCH]` | move a scratch session's work into a real repo |
 | `brindle ls [--all]` | workspaces and agents |
 | `brindle repo add PATH [--name ALIAS] / rm ALIAS / ls` | attach other local repos to the current session so workers can go there (brindle Pro; see "Several repos in one session") |
+| `brindle keys set/unset/list [NAME]` | store model API keys (e.g. `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`) once in the OS keychain (or a 0600 file); every agent pane gets the ones its provider reads, unless you already export it. `set` reads the value from a hidden prompt or stdin, `list` shows names and the last 4 characters. `CLAUDE_CODE_OAUTH_TOKEN` (a Claude subscription token) is never stored |
 | `brindle history [--limit N] [--kind K] [--all]` | durable log of worker results, reviews, merges and milestone checks |
 | `brindle cost [--days N] [--all]` | dollar spend at list prices over the last 30 days, by model |
 | `brindle cost report [--days N] [--all]` | Pro: spend by day, profile and goal, cost per merged branch, review pass rate per worker profile |
@@ -331,7 +332,8 @@ your own status line prints, so what you see doesn't change.
 | `brindle cost estimate [--tasks N] [--weight W] [--profile P] [--reviewer R]` | what the current goal (or N tasks) is likely to cost, as a range from this repo's history (median to p80 of past worker and review runs), plus a cheaper alternative with a different reviewer; says "low confidence" when there's too little history. Also added to `set_goal` and `assign` replies (brindle Pro) |
 | `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\|org]` | paid features: bare `brindle account` shows what your plan has and how to get the rest (see "brindle Pro and Team" below) |
+| `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 |
@@ -496,6 +498,7 @@ Autopilot, merge gates and cleanup:
 | `max_agents` | `4` | workers running at once per session (`0`: no cap) |
 | `check_timeout` | `900` | seconds each check may take |
 | `check_concurrency` | `2` | check runs at once on this machine, across branches; the rest wait their turn (`0`: no cap). A run far past its last duration is reported to the supervisor |
+| `fable_escalation` | on, unless the worker runs on a cloud account (Bedrock, Vertex or Foundry) | retry a failed heavy task once on `developer-heavy` (Fable) before handing it to you; `true` turns it on for a cloud account, `false` off |
 | `usage_limit` | `90` | autopilot stops pushing on at this % of your Claude usage limit |
 | `limit_cooldown_minutes` | `300` for Antigravity | how long a provider that hit its limit counts as unavailable |
 | `graphify` | if the graph is there | point agents at the repo's [graphify](https://github.com/safishamsi/graphify) code map (`false` turns it off) |
@@ -559,9 +562,9 @@ keep theirs):
 ```json
 {
   "routing": {
-    "light":  ["developer", "developer-codex", "developer-local"],
+    "light":  ["developer-light", "developer", "developer-codex", "developer-local"],
     "medium": ["developer", "developer-codex", "developer-heavy"],
-    "heavy":  ["developer-heavy", "developer", "developer-codex"]
+    "heavy":  ["developer", "developer-heavy", "developer-codex"]
   }
 }
 ```
@@ -569,7 +572,9 @@ keep theirs):
 No tier prefers another provider for its own sake: all-Claude or all-Codex may
 be what works best for you, and that's for the learner to find out.
 
-`developer-codex` runs on Codex; `developer-heavy` on Claude Fable at high effort.
+`developer-light` runs on Claude Haiku at low effort; `developer` on your Claude
+Code default model; `developer-codex` on Codex; `developer-heavy` on Claude Fable
+at high effort.
 A profile is skipped when its CLI isn't installed (`claude`, `codex`, `agy`), the
 local model server isn't answering, or its provider is at your `usage_limit`. If
 hosted learning is on it chooses among the profiles left; otherwise the first
@@ -728,11 +733,14 @@ 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
 brindle account upgrade    # opens the checkout for brindle Pro (and prints its URL)
-brindle account portal     # opens the billing portal (invoices, seats, cancellation); --org ORG for a team org
+brindle account upgrade --enterprise [--trial] --seats N --org ORG   # brindle Enterprise for a team org; --trial: free trial, at most 10 seats
+brindle account portal     # opens the billing portal (invoices, payment method, cancellation); --org ORG for a team org
+brindle account seats N    # set a Team or Enterprise org's seat count (billing admin); --org ORG; Stripe prorates the change
 brindle account org list   # the orgs you belong to; `org use <id>` switches, `org policy` shows the current one
 brindle account org policy # the org's policy, its per-role overrides, and the policy that applies to you
 brindle account org profiles                                  # the org's shared profiles and rule packs, and which are pinned
@@ -742,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
@@ -795,6 +848,16 @@ entitlement.
 * `deny_personal_keys`: the personal model keys (`ANTHROPIC_API_KEY`,
   `OPENAI_API_KEY`, ...) are taken out of every agent pane, and a profile that
   sets one is refused.
+* An org-owned key: with `provider` `anthropic` (or `openai-compatible`), set
+  `key_env` to the name of a variable that holds the org's key (not a personal
+  one like `ANTHROPIC_API_KEY`), or `key_helper` to a command, as a list of
+  arguments, that prints the key (for example `["vault", "kv", "get",
+  "-field=key", "secret/anthropic"]`). brindle runs the helper on the person's
+  machine, without a shell and with a timeout, each time a worker starts, and
+  gives the key to that worker as `ANTHROPIC_API_KEY` (`OPENAI_API_KEY` for
+  Codex). It passes `deny_personal_keys`; a personal key doesn't. The key never
+  goes through brindle's servers. When the variable is missing or the helper
+  fails, the worker doesn't start.
 
 Two things to know when you turn on `deny_personal_keys`:
 
@@ -955,17 +1018,31 @@ workflows call these commands:
   commits the workflows on a `brindle/ci-setup` branch, then puts you back on
   the branch you started on and deletes the local setup branch, so `git pull`
   after merging the setup pull request is clean (commit or stash your changes
-  first: it refuses to start with uncommitted work).
+  first: it refuses to start with uncommitted work). With your own cloud
+  (`--credential bedrock|vertex|foundry`, keyless GitHub OIDC) it can read the
+  IDs from the deployment template's outputs instead of asking:
+  `--from-stack NAME [--region R]` (AWS CloudFormation), `--from-terraform DIR`
+  (Google) or `--from-deployment NAME -g RG` (Azure). They are defaults for
+  `--cloud-var`, which still overrides them, and every ID is format-checked. A
+  missing `aws`, `terraform` or `az` CLI or output is an error that names the
+  `--cloud-var` to pass instead. Vertex AI and Microsoft Foundry are in
+  **preview** (not yet verified end to end): `init` refuses them unless you pass
+  `--preview` or set `BRINDLE_CI_PREVIEW_CLOUDS=1`, and `doctor` marks them
+  `(preview)`. Bedrock is generally available.
 - `brindle ci doctor`: which provider CLIs and credential names a runner has, and
-  which providers CI may use on this repository.
+  which providers CI may use on this repository. `--models` also makes one tiny
+  call per pinned model and says why any is refused (a quota, a form not filled in).
 - `brindle ci start`: start a run for an issue, a goal text or a dispatched run,
   or a validation of a pull request.
 - `brindle ci run`: run what was started: the supervisor and the result upload,
   or the pull request's checks and reviews and the evidence upload.
 - `brindle ci report`: tell the service how the workflow's jobs ended.
 
-Credential names are reported, never values. On a repository owned by a GitHub
-organization, a provider signed in only with a personal subscription is not used.
+Credential names are reported, never values. CI uses API keys, cloud sign-ins
+(Bedrock, Vertex, Foundry) or identity federation only: a provider signed in
+only with a subscription (`CLAUDE_CODE_OAUTH_TOKEN`, a Codex ChatGPT login) is
+not used, on personal and organization repositories alike. Add an API key
+secret instead.
 
 Fix builds only fix the default branch's *required* status checks, and a new
 repository has none. When the default branch requires none, `brindle ci init`
@@ -1198,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.
@@ -1210,6 +1287,16 @@ needs no browser step. Put the key in your environment, or in a profile's
 `brindle doctor` names the variable each CLI gets, from your shell or from
 which profiles.
 
+A profile chooses between the two with `auth`:
+
+| `auth:` | What the worker signs in with |
+|---|---|
+| `auto` (default) | A key from your environment or `brindle keys` if there is one, else the CLI's own login. |
+| `subscription` | Always the CLI's own login: brindle strips that provider's API keys from the pane. |
+| `api_key` | Only a key: the worker refuses to start without one. |
+
+Your org's `deny_personal_keys` (Enterprise) still applies on top of `auth`.
+
 ### Cheap workers
 
 By default a Claude Code worker loads everything your own `claude` does: your
@@ -1596,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.2.1 → brindle-0.3.1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "brindle"
-version = "0.2.1"
+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"
@@ -52,6 +52,8 @@ audit_export = "brindle.pro.audit_export:make"
 dev = [
     "pytest>=8",
     "pytest-xdist>=3.8.0",
+    "python-hcl2>=8.1.4",
+    "pyyaml>=6.0.3",
 ]
 
 [build-system]