# Claude Code 2.1.207 conductor compatibility proof

Date: 2026-07-11
Scope: CD-01, human-started interactive conductor only

## Environment

- Claude Code `2.1.207` using first-party Claude Max subscription auth
- tmux `3.6`
- OMS launched with `bin/oms conductor start`; no print/headless Claude mode
- Model resolved from policy to Opus; Fable was shown only as an optional Claude UI notice and was not selected

## Observed results

1. The command created the `oms:conductor` pane and attached an interactive TTY.
2. `/mcp` showed exactly one server, `oms`, connected with two tools. The launch uses `--strict-mcp-config` and `--no-chrome`.
3. `propose_goal` persisted a version-0 canonical goal containing repository/queue scope, stopping condition, `until-empty`, `subscription-only`, `default`, and a stable nonce.
4. The literal objective text `$(touch /tmp/oms-conductor-injection)` remained data. The named file was not created.
5. A schema-valid `propose_dispatch` call returned `{"status":"dispatch-not-enabled"}` and created no ticket, lease, worker, or worktree state.
6. After killing and recreating the tmux session, `oms conductor start` reused the persisted Claude session UUID and resumed the prior conversation.
7. The launch advertises only `Read`, `Glob`, `Grep`, `mcp__oms__propose_goal`, and `mcp__oms__propose_dispatch`; provider-plan tests reject Edit, Write, Bash, raw tmux, web, agent, print, and background authority.

The smoke exposed one real-client detail before passing: Claude Code includes an MCP `_meta` envelope on tool calls. OMS now accepts that protocol metadata while continuing to validate the tool payload against a closed schema.

This is compatibility evidence for the pinned version, not a general certification of later Claude Code versions, billing behavior, unattended execution, worker dispatch, merge, or release readiness.
