Switch coding-agent plugins to the Rust daemon

Replace the legacy Codex TypeScript runtime and Claude shell state machine with fail-open launchers for the shared bt daemon. This reapplies the exact plugin source migration split out of the daemon infrastructure PR and is intentionally stacked until a daemon-capable bt release is available.

Signed-off-by: Stephen Belanger <stephen.belanger@braintrustdata.com>

Author: Qard

src/plugins/claude/content/CONTRIBUTING.md

@@ -1,246 +1,89 @@
-# Development of the plugin itself
+# Development of the plugins
 
 ## Prerequisites
 
-- Python 3.12+
-- [uv](https://docs.astral.sh/uv/) package manager
+- Python 3.12+ and [uv](https://docs.astral.sh/uv/) for the Braintrust skill
+  evals.
+- Rust for the shared tracing daemon.
+- `jq` for plugin manifest validation and the optional fixture recorder.
 
 ## Local testing
 
-Test a plugin without installing from marketplace:
+Load a plugin directly without installing it from the marketplace:
 
 ```bash
-claude --plugin-dir /path/to/thisrepo/plugins/{plugin dir here}
-# example
-claude --plugin-dir /path/to/thisrepo/plugins/braintrust
+claude --plugin-dir /path/to/repo/plugins/braintrust
+claude --plugin-dir /path/to/repo/plugins/trace-claude-code
 ```
 
 ## Running evals
 
-The `evals/` directory contains tests that verify the plugin works correctly (e.g., Claude generates valid SQL queries, logs data properly).
+The `evals/` directory verifies that Claude can use Braintrust workflows:
 
 ```bash
 cd evals
 export BRAINTRUST_API_KEY="your-key"
-
-# Run all evals
 uv run braintrust eval .
-
-# Run specific eval
-uv run braintrust eval eval_e2e_log_fetch.py
 ```
 
-## Pre-commit hooks
-
-```bash
-# Install hooks
-uv run pre-commit install
+## Testing `trace-claude-code`
 
-# Run all hooks
-uv run pre-commit run --all-files
-```
+The plugin contains only a fail-open `bt` hook shim. All event translation and
+Braintrust delivery live in the shared Rust daemon at `bt-daemon/`.
 
-## Testing the `trace-claude-code` plugin
+From the monorepo root:
 
-Bash test suite for the hook scripts. Tests run the hooks against a
-stubbed `curl`, capture the resulting HTTP requests, and assert on the
-inferred span tree.
-
-### Running
-
-```sh
-# From the repo root:
+```bash
+cargo test --manifest-path bt-daemon/Cargo.toml --all-features
+cargo clippy --manifest-path bt-daemon/Cargo.toml --all-targets --all-features -- -D warnings
 make test
-
-# Or run a specific test file:
-bash plugins/trace-claude-code/test/run_tests.sh test_e2e
-bash plugins/trace-claude-code/test/run_tests.sh test_replay test_queue
 ```
 
-### Layout
-
-```
-plugins/trace-claude-code/test/
-├── helpers/
-│   ├── assert.sh        # describe / it / assert_eq / assert_contains, color output
-│   ├── harness.sh       # setup_test_env, teardown_test_env, run_hook
-│   ├── curl_stub.sh     # curl() shell function that captures requests + returns canned responses
-│   ├── fixtures.sh      # builders for hook input JSON (fixture_session_start, etc.)
-│   ├── span_tree.sh     # all_spans, span_count_by_type, span_by_name, children_of, ...
-│   └── replay.sh        # replay_session, describe_fixture
-├── fixtures/
-│   └── sessions/        # captured Claude sessions used by test_replay.sh
-├── test_*.sh            # one file per area
-├── record_session.sh    # CLI to prep a fixture directory for capturing
-└── run_tests.sh         # entry point
-```
+`bt-daemon/tests/claude_translator.rs` covers synthetic lifecycle cases and
+replays the immutable captured sessions under
+`plugins/trace-claude-code/test/fixtures/sessions/`. Add translator behavior and
+assertions there, not as another hook script.
 
-### Writing a test
+### Capturing a fixture
 
-Each `test_*.sh` follows this pattern:
+Set `BRAINTRUST_RECORD_DIR` to a new absolute directory before running Claude:
 
 ```bash
-#!/bin/bash
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-source "$SCRIPT_DIR/helpers/assert.sh"
-source "$SCRIPT_DIR/helpers/harness.sh"
-
-describe "my feature"
-
-t_my_test_body() {
-    # setup_test_env has already created an isolated $HOME and stubbed curl
-    stub_response_for "*/v1/project_logs/*/insert" 200 '{"row_ids":["row_1"]}'
-
-    run_hook session_start.sh "$(fixture_session_start "s1" "/tmp/x")"
-
-    assert_eq "$(span_count_by_type task)" "1"
-}
-
-it "does the thing" t_my_test_body
-```
-
-Key conventions:
-
-- `describe "..."` is a section header (purely visual).
-- `it "name" function_name` runs `function_name` between `setup_test_env`
-  and `teardown_test_env`, then prints a ✓ or ✗.
-- Assertions (`assert_eq`, `assert_contains`, `assert_failure`, ...) record
-  failures into the current test but do **not** abort. Multiple assertions
-  per test are fine.
-- Hooks are run synchronously in tests via `BRAINTRUST_SYNC_QUEUE=true`
-  set by `setup_test_env`. Span queue tests opt out of this when needed.
-
-### Capturing a real session as a test fixture
-
-The hooks support recording every invocation to disk when the env var
-`BRAINTRUST_RECORD_DIR` is set. The recorded data can then be replayed
-in a test.
-
-#### 1. Prepare a fixture directory
-
-```sh
-plugins/trace-claude-code/test/record_session.sh my-fixture
+export BRAINTRUST_RECORD_DIR=/absolute/path/to/new-fixture
+claude --plugin-dir /path/to/plugins/trace-claude-code
 ```
 
-This prints a `BRAINTRUST_RECORD_DIR` value pointing at
-`test/fixtures/sessions/my-fixture/`.
-
-#### 2. Run Claude Code with recording on
+The shim appends `{ts, hook, payload}` records to `events.ndjson` and copies
+referenced main/subagent transcripts under `transcripts/`. Move a reviewed,
+credential-free capture under `test/fixtures/sessions/`, add its contract to
+the Rust test, and run the full daemon suite. The daemon’s normal recovery
+journal independently embeds transcript snapshots at lifecycle boundaries.
 
-```sh
-export BRAINTRUST_RECORD_DIR=/abs/path/to/test/fixtures/sessions/my-fixture
-claude
-# ... use Claude Code normally ...
-```
-
-While `BRAINTRUST_RECORD_DIR` is set:
-
-- Every hook invocation appends one NDJSON record to
-  `events.ndjson` containing `{ts, hook, payload}`.
-- The `stop_hook` also copies the referenced transcript file into
-  `transcripts/<session_id>.jsonl`.
-
-You do not need to modify hook scripts or set anything else - the recorder
-runs inside the existing hooks.
-
-#### 3. Inspect the fixture
-
-```sh
-plugins/trace-claude-code/test/record_session.sh --describe my-fixture
-```
-
-Output:
-
-```
-Fixture: .../test/fixtures/sessions/my-fixture
-  Events: 14
-  Hook counts:
-    post_tool_use: 8
-    session_end: 1
-    session_start: 1
-    stop_hook: 3
-    user_prompt_submit: 1
-  Transcripts: 1
-```
-
-#### 4. Replay it in a test
+## Pre-commit hooks
 
 ```bash
-t_replay_my_fixture() {
-    stub_response_for "*/v1/project_logs/*/insert" 200 '{"row_ids":["row_1"]}'
-
-    local n
-    n=$(replay_session "$SCRIPT_DIR/fixtures/sessions/my-fixture")
-    assert_success "$?"
-    assert_eq "$n" "14"
-
-    # Now assert on the span tree the hooks produced
-    assert_eq "$(span_count_by_type tool)" "8"
-    assert_eq "$(span_count_by_type llm)"  "3"
-}
-
-it "my real-world fixture produces the expected spans" t_replay_my_fixture
+uv run pre-commit install
+uv run pre-commit run --all-files
 ```
 
-The replayer:
-
-- Reads `events.ndjson` line by line in order.
-- For `stop_hook` events, rewrites `payload.transcript_path` to point at
-  the bundled transcript so the replayed hook can read it.
-- Invokes the matching hook script via `run_hook` with the recorded
-  payload.
-
-#### When to use replay vs. synthetic fixtures
-
-- **Synthetic fixtures** (`fixture_session_start`, etc.) - fast to write,
-  test specific scenarios in isolation, no real Claude needed.
-- **Replayed fixtures** - high-fidelity regression tests of real-world
-  interactions. Use when you want to lock in behavior on a specific
-  pattern of hooks you saw in the wild (e.g. a session with parallel
-  tool calls, or a long multi-turn conversation).
-
-### Span-tree queries
-
-The captured HTTP requests are parsed to extract the inserted spans. Available helpers:
-
-| Function | Returns |
-|---|---|
-| `all_spans` | JSON array of every span sent to any `/insert` endpoint |
-| `span_count` | total number of spans |
-| `span_count_by_type "tool"` | count of spans with `span_attributes.type == "tool"` |
-| `spans_named "^Turn "` | array of spans whose name matches the regex |
-| `span_by_name "^Turn 1$"` | first matching span (or `null`) |
-| `span_by_type "llm"` | first span of that type |
-| `span_by_id "..."` | span with the given `span_id` |
-| `children_of "<span_id>"` | array of spans whose first parent is the given id |
-| `is_child_of "<child_id>" "<parent_id>"` | exit 0 if true |
-
-All return JSON on stdout; combine with `jq` for further drilling.
-
 # Releasing a plugin
 
-Releases are manual and git-driven. There are no git tags or publish automation: pushing to `main` is the release.
-
-## How version resolution works
-
-Claude Code resolves a plugin's version from the first of these that is set:
-
-1. `version` in the plugin's `plugins/<plugin>/.claude-plugin/plugin.json`
-2. `version` in the plugin's entry in `.claude-plugin/marketplace.json`
-3. The git commit SHA of the plugin's source
+Releases are manual and git-driven. There are no git tags or publish
+automation: pushing to `main` is the release.
 
-Both plugins set `version` in their own `plugin.json`, and the marketplace entries do **not** declare a per-plugin `version`. So **each plugin's `plugin.json` is the sole authority for its version**, and bumping it is what triggers updates for users.
+Claude Code resolves a plugin version from the first available source:
 
-The top-level `version` field in `marketplace.json` is just marketplace-manifest metadata. It does **not** gate plugin updates.
+1. `version` in `plugins/<plugin>/.claude-plugin/plugin.json`
+2. `version` in its marketplace entry
+3. the source commit SHA
 
-> [!WARNING]
-> Do not add a `version` field to a plugin's entry in `marketplace.json`. The `plugin.json` value always wins silently, so a stale marketplace version can mask the real one. Keep the version in `plugin.json` only.
+Each plugin’s `plugin.json` is authoritative. Do not add a per-plugin version
+to `marketplace.json`; a stale duplicate can mask the real version.
 
-## Release steps
+Release steps:
 
-1. Bump `version` in the plugin's manifest:
-   - `plugins/braintrust/.claude-plugin/plugin.json`, or
-   - `plugins/trace-claude-code/.claude-plugin/plugin.json`
-2. (Optional) Bump the top-level `version` in `.claude-plugin/marketplace.json` for bookkeeping. This is cosmetic and does not affect whether users receive the update.
-3. Commit and push to `main` (via PR).
-4. Users update with: `claude plugin marketplace update braintrust-claude-plugin`
+1. Bump the plugin’s `.claude-plugin/plugin.json` version.
+2. Optionally bump the marketplace manifest’s top-level bookkeeping version.
+3. Commit and merge through a PR.
+4. Users update with
+   `claude plugin marketplace update braintrust-claude-plugin`.

src/plugins/claude/content/Makefile

@@ -1,8 +1,9 @@
 .PHONY: test test-trace-claude-code
 
-# Run all plugin tests
 test: test-trace-claude-code
 
-# Run trace-claude-code plugin tests
 test-trace-claude-code:
-	@bash plugins/trace-claude-code/test/run_tests.sh
+	@sh -n plugins/trace-claude-code/bin/claude-hook.sh
+	@jq empty plugins/trace-claude-code/hooks/hooks.json
+	@grep -q "'daemon','hook','--source','claude-code'" plugins/trace-claude-code/bin/claude-hook.cmd
+	@echo "trace-claude-code shims OK"

src/plugins/claude/content/README.md

@@ -10,7 +10,8 @@ A Claude Code plugin marketplace for [Braintrust](https://braintrust.dev) integr
 ## Prerequisites
 
 - A [Braintrust account](https://braintrust.dev)
-- `BRAINTRUST_API_KEY` exported in your environment
+- The [`bt` CLI](https://bt.dev/cli/install.sh), authenticated with `bt auth login`,
+  or `BRAINTRUST_API_KEY` exported in your environment
 
 ## Installation
 
@@ -37,31 +38,45 @@ claude plugin install braintrust@braintrust-claude-plugin
 
 ### trace-claude-code
 
-Automatically traces Claude Code conversations to Braintrust. Captures sessions, conversation turns, and tool calls as hierarchical traces.
+Automatically traces Claude Code conversations to Braintrust through the
+shared local `bt` daemon. Captures sessions, turns, model calls, tool calls,
+subagents, tool failures, and permission denials as hierarchical traces.
 
 ```bash
 claude plugin install trace-claude-code@braintrust-claude-plugin
 # run the setup script to confgure tracing
 $HOME/.claude/plugins/marketplaces/braintrust-claude-plugin/plugins/trace-claude-code/setup.sh
 ```
 
-Traces are sent to the `claude-code` project by default.
+The setup script enables tracing in the daemon's shared non-credential
+`config.json`. The project selected there applies to every coding-agent plugin
+connected to the daemon.
+
+The tracing launchers live under `plugins/trace-claude-code/bin/` as
+`claude-hook.sh` and `claude-hook.cmd`. The Windows launcher forwards the same
+configuration to `bt`, whose daemon uses a local named pipe on Windows.
 
 #### manual configuration
 
-Instead of running `setup.sh`, you can manually edit `~/.claude/settings.json` or your project's `.claude/settings.local.json`:
+Instead of running `setup.sh`, create the daemon's shared config at
+`$BT_DAEMON_CONFIG`, or at `config.json` inside `$BT_DAEMON_DATA_DIR` (by
+default `~/.braintrust/state/bt-daemon/config.json` on Unix):
 
 ```json
 {
-  "env": {
-    "TRACE_TO_BRAINTRUST": "true",
-    "BRAINTRUST_CC_PROJECT": "project-name-to-send-cc-traces-to",
-    "BRAINTRUST_API_KEY": "sk-yourkey",
-    "BRAINTRUST_DEBUG": "false"
-  }
+  "traceToBraintrust": true,
+  "project": "coding-agents",
+  "flushOnTurnEnd": false,
+  "additionalMetadata": {"team": "platform"}
 }
 ```
 
+This file intentionally contains no API keys, auth tokens, credentials, or
+backend URLs. Those come from the authenticated `bt` CLI. The legacy
+`TRACE_TO_BRAINTRUST`, `BRAINTRUST_CC_PROJECT`,
+`BRAINTRUST_FLUSH_ON_TURN_END`, and `BRAINTRUST_ADDITIONAL_METADATA`
+environment variables remain fallbacks for omitted shared settings.
+
 #### add claude code trace to an existing trace
 
 You can attach a Claude Code session to an existing Braintrust trace by passing `CC_PARENT_SPAN_ID`:
@@ -78,11 +93,12 @@ claude --settings '{"env":{"CC_PARENT_SPAN_ID":"parent-span-id","CC_ROOT_SPAN_ID
 
 The Claude Code session and all its turns/tools will appear as children of your parent span in Braintrust.
 
-To attach claude code to an experiment's trace, specify CC_EXPERIMENT_ID as well:
+To route the session into an existing experiment instead of project logs, set
+`CC_EXPERIMENT_ID`.
 
-```bash
-claude --settings '{"env":{"CC_PARENT_SPAN_ID":"parent-span-id","CC_ROOT_SPAN_ID":"root-span-id", "CC_EXPERIMENT_ID":"the-experiment-id"}}' -p "task"
-```
+Set `BRAINTRUST_RECORD_DIR` to capture native hook events and transcript
+snapshots for a reproducible local fixture. The daemon also embeds transcript
+snapshots in its redacted recovery journal at lifecycle boundaries.
 
 #### token accounting
 

src/plugins/claude/content/plugins/trace-claude-code/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "trace-claude-code",
   "description": "Automatically trace Claude Code conversations to Braintrust for observability. Captures sessions, conversation turns, and tool calls as hierarchical traces.",
-  "version": "1.5.0",
+  "version": "2.0.0",
   "author": {
     "name": "Braintrust"
   }