Setup

---
name: setup
description: Configure, authenticate, repair, and verify the Codex to Claude Code Bridge; safe stages run by default and sensitive stages require separate approval.
---

> Before asking, read [User Questions](../../rules/codex-user-questions.md).

# Set Up the Bridge

## Bootstrap and plan

- Treat a plain invocation as `action=all target=peer scope=auto live=prompt`.
- Loaded Codex plugin, Codex trust, Codex authentication, and current session are external bootstrap prerequisites. Never replace or restart current invocation surface.
- Reject a model-controlled workspace override. The deterministic setup CLI uses its trusted host-selected workspace; installed MCP execution separately requires native user-confirmed binding and a current `binding_id`.
- Resolve the active installed plugin root and substitute it for `PLUGIN_ROOT`. Setup helpers use the packaged launcher; on native Windows use `bin/python.cmd` with host-shell quoting. MCP startup still requires Python 3.10+ as `python` on the host's PATH; the helper launcher does not satisfy or change that separate prerequisite.
- Parse only `action=all|check|configure|authenticate|repair|verify-live`, `target=peer|codex|claude`, `scope=auto|user|project|local`, and `live=prompt|skip|required`, plus one-release compatibility forms `--live` and `--direction codex|claude`; reject ambiguous or unknown arguments.

For one resolved target, invoke:

```bash
"PLUGIN_ROOT/bin/python" "PLUGIN_ROOT/bin/bridge_setup.py" --current-host codex --workspace "<launch-workspace>" --action "<action>" --target "<target>" --scope "<scope>" --live "<live>"
```

Credential-free planner returns setup result JSON defined by `schemas/setup-result.schema.json`.

> Route configuration/repair, authentication, and paid live-verification decisions separately through User Questions. Bind each answer to its own current action digest after displaying effects; generic approval never carries to another stage. Preserve digest confirmation syntax, operator-terminal login, cost disclosure, and denial/replay/expiry stops. Host-side answers are not guest authorization or runtime permission.

## Check and approved changes

For `check`, report the result and stop. For `all`, `configure`, or `repair`:

1. Show every planned `operations` entry and the approval digest before mutation.
2. Obtain explicit approval for exactly that digest. State:
   - action and purpose;
   - exact native argv and resolved target/scope;
   - external capability;
   - credential behavior;
   - filesystem and host-configuration effects;
   - rollback evidence;
   - retry policy; and
   - safe denial outcome.
3. After approval, rerun the identical command with `--approve "<approval_digest>"`.

> Host-held HMAC makes digest tamper-evident but does not grant consent; explicit operator or host approval remains required. The digest is action-bound, expires, and is consumed by its first execution attempt. Never substitute `--approve` without its digest. Denial, changed or expired digest, replay, unsupported capability, failed probe, or failed operation stops without retry.

## Authentication and session evidence

When authentication remains:

1. Re-plan the provider-owned interactive login with identical host, workspace, target, scope, and live values but `--action authenticate`.
2. Obtain separate approval for that action's digest and state exact `authentication_argv` may open a browser and use network and account state.
3. Give operator identical authenticate command plus `--approve "<authentication_digest>"` to run in their own terminal.

> Sensitive phase: never run through a model-controlled shell or another captured tool stream. Bridge then launches only native login command with terminal inherited. Never accept, request, pipe, echo, inspect, or store a token, API key, browser code, device code, email, or raw login output. Process exit means `auth-flow-launched`; only a later redacted status probe may establish `host-authenticated`.

Use `bridge_status` from loaded MCP inventory before claiming current session or workspace readiness. `binding_status=unbound` means the installed server is loaded but no project is selected; never call that a stale installation or a workspace mismatch. Invoke `bridge_bind_workspace` with empty arguments and let the user type the project folder, then separately confirm its exact canonical path through native forms. Require `binding_status=bound`, a nonempty current `binding_id`, and the intended canonical workspace before executable calls; pass that ID with each `task`. Expected inventory includes `bridge_bind_workspace` plus status and the three executable tools. Rebinding invalidates old IDs immediately, including cancelled rebinds. Binding selects project identity; it grants no editing approval, runtime permission, authentication, or paid-call consent. Static planner cannot establish this evidence.

## Live verification

When `live=prompt` or `live=required` reaches `inference-unverified`:

1. Re-plan with identical host, workspace, target, and scope but `--action verify-live`.
2. Obtain a third approval for that action's digest and one paid provider call.
3. State network, installed-CLI-managed credential, quota/cost, workspace, and point-in-time semantics.
4. Rerun that same verify-live command with `--approve "<live_digest>"`.

> Never invoke the lower-level live doctor outside this approval path. Successful live CLI result remains partial until applicable loaded-session/workspace evidence also present. `live=skip` remains `inference-unverified`; never call it ready. Denial under `live=required` is non-ready.

## Completion boundary

- Setup always owns one resolved peer target.
- To prepare both integrations, finish peer lifecycle from Codex, start any required fresh session, then run `/bridge:setup` from Claude for its peer; no digest, state claim, or readiness result is shared between hosts.
- Loaded-host branch is check/bootstrap-only, never mutates its current invocation surface.
- Report strongest verified level, exact remaining action, confidence, and limits.

> Never equate static readiness, process exit, host authentication, session readiness, workspace readiness, or live verification.