setup
Configure, authenticate, repair, and verify the Codex to Claude Code Bridge; safe stages run by default and sensitive stages require separate approval.
Install
npx skills add https://github.com/Borda/AI-Rig/tree/main/plugins/bridge_cc-codex/codex-skills/setup
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install borda-ai-rig@llmmart
git clone https://github.com/Borda/AI-Rig.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole borda/ai-rig collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Before asking, read User Questions.
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; use host-selected launch workspace.
- Require
python --version>= 3.10. - Parse only
action=all|check|configure|authenticate|repair|verify-live,target=peer|codex|claude,scope=auto|user|project|local, andlive=prompt|skip|required, plus one-release compatibility forms--liveand--direction codex|claude; reject ambiguous or unknown arguments.
For one resolved target, invoke:
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:
- Show every planned
operationsentry and the approval digest before mutation. - 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.
- 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
--approvewithout 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:
- Re-plan the provider-owned interactive login with identical host, workspace, target, scope, and live values but
--action authenticate. - Obtain separate approval for that action's digest and state exact
authentication_argvmay open a browser and use network and account state. - 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 establishhost-authenticated.
Use bridge_status from loaded MCP inventory before claiming current session or workspace readiness. Its canonical workspace must equal host-selected launch workspace and its expected tool inventory must match current Bridge contract. Static planner cannot establish this evidence.
Live verification
When live=prompt or live=required reaches inference-unverified:
- Re-plan with identical host, workspace, target, and scope but
--action verify-live. - Obtain a third approval for that action's digest and one paid provider call.
- State network, installed-CLI-managed credential, quota/cost, workspace, and point-in-time semantics.
- 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=skipremainsinference-unverified; never call it ready. Denial underlive=requiredis 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:setupfrom 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.
Files (ai-rig)
-
SKILL.md 5 KB
--- 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; use host-selected launch workspace. - Require `python --version` >= 3.10. - 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 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. Its canonical workspace must equal host-selected launch workspace and its expected tool inventory must match current Bridge contract. 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.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.