⚙ Prerequisites

Before installing CSI, make sure the following tools are available on your system:

⇓ Run the installer

Run the following command in your terminal. The installer will download and configure CSI automatically:

curl -Ls aliasrobotics.com/get_csi | sh

API key setup

During installation you will be prompted to enter your Alias API key. This key was sent to your registered email address. Copy it from your inbox and paste it when asked.

CAI environment (.env) — optional

If you use the CAI scaffold (CSI_BACKEND=cai csi), CAI loads a project .env from the working directory inside the container. CSI maps that to ~/.csi/workspace/.env on your host (mounted as /workspace).

After the API key step, the installer asks for an optional path to a local CAI git clone. If the repo has a .env at its root, the installer links it:

~/.csi/workspace/.env  →  /path/to/your/cai/.env

Press Enter to skip — the installer creates a minimal default ~/.csi/workspace/.env instead (includes your ALIAS_API_KEY and CAI_COMPACT_REPL=0).

To reconfigure later without a full reinstall:

~/.csi/setup-cai-env.sh --configure          # interactive prompt
~/.csi/setup-cai-env.sh --link ~/path/to/cai  # link repo .env directly

Closing the Docker container does not modify your linked .env. Session-only changes made with /env set inside CAI are not written back to disk.

Step-by-step summary

• 1
  Open a terminal

  Any standard terminal on Linux or macOS.
• 2
  Run the installer

  curl -Ls aliasrobotics.com/get_csi | sh
• 3
  Enter your API key

  Paste the key from your email when the installer prompts you.
• 4
  Link CAI repo .env (optional)

  Enter the path to your CAI clone, or press Enter for the default ~/.csi/workspace/.env.
• 5
  Installation complete

  CSI is installed and ready to use.

▶ First run

To launch CSI, open a terminal and run:

csi

CSI will start and guide you from there. No additional arguments are required to get started.

☷ Scaffold routing

Whichever scaffold you launch, its API traffic is pointed at the proxy on 127.0.0.1. A single model identifier — an alias* model, an OpenRouter slug, an Anthropic model, or a custom endpoint — reaches the right upstream regardless of which scaffold dispatched it.

All upstreams speak Chat Completions; the proxy translates to each backend’s wire format (Anthropic /v1/messages for Claude Code, the Responses API for Codex). Every request is appended to ~/.csi/logs/csi_<uuid>.jsonl with route, model, status, tokens, cost and timing.

🔒 Telemetry defense

Telemetry control is a property of the harness, so it applies to every scaffold, not a single backend. By default (CSI_TELEMETRY_FILTER=1) CSI keeps non-essential traffic off the wire through up to three independent layers. The proxy whitelist (Layer 3) is universal — it governs all backends; scaffolds running on a JavaScript runtime gain two additional layers at the environment and network level.

                         csi  (wrapper)
       CSI_BACKEND = cc | claude | codex | cai | gcai | mistral
                               |
   +-----------+-----------+---+-------+-----------+-----------+
 CSI::Claude  CSI::Codex  CSI::CAI  CSI::GCAI  CSI::Mistral
 (cc/claude)  (Rust)      (Python)  (in-tree)  (vibe)
     |            |           |          |           |
 ANTHROPIC    OPENAI      ALIAS      (proxy)     (proxy)
 _BASE_URL    _BASE_URL   _BASE_URL
     +------------+-----------+----------+-----------+
                              v
  +============================================================+
  |  L3  Local routing proxy        127.0.0.1:PORT             |
  |      - wire translation   Anthropic  <->  OpenAI           |
  |      - /model switching   +  quota preflight check         |
  |      - telemetry whitelist (non-API paths blocked)         |
  |      - JSONL logging      +  cost ledger per request       |
  +====+================+================+=====================+
       v                v                v
   alias*           openrouter/*     claude-* / custom
   Alias API        OpenRouter       Anthropic / self-hosted
   (:666)           (OR_API_KEY)     (OAuth / key)

⚙ Agent view (csi agents)

CSI’s multi-scaffold equivalent of claude agents: one TUI to dispatch, monitor, attach to, reply to and stop background sessions across every scaffold — each job routed through the shared proxy so a single model identifier reaches the right upstream from whichever scaffold dispatched it.

# open the cross-scaffold roster
csi agents

# one-shot dispatch (fire and forget)
csi agents "investigate the flaky settings test"
CSI_BACKEND=codex csi agents "summarise this branch"

• Cross-scaffold roster with live state (working / done / blocked / failed).
• Real-terminal attach via tmux — the scaffold’s own UI, no transcript replay.
• Reply straight into a live REPL; Ctrl-C double-tap detaches without killing the session.
• One persistent proxy per user; a guard child stops it after 60 s idle.

   csi agents   (Ink TUI - cross-scaffold roster)
     > * [cc]    fix auth bug        1m
       * [gcai]  audit scan          4m
                 |  dispatch{ scaffold, model, prompt }
                 v
       adapter.dispatch()  -> tmux pane per scaffold
        cc . claude . codex . cai . gcai . vibe
                 |  ANTHROPIC_BASE_URL = 127.0.0.1:
                 v
       shared proxy (detached) + guard child
        - one API JSONL    - idle 60s -> SIGTERM
        - polls roster.json  - 12h hard ceiling

☷ The alias model family

Alias Robotics trains a family of cybersecurity-specialized LLMs. Any of them is reachable through CSI with --model (or the ANTHROPIC_MODEL default), routed by the proxy — see Model routing.

csi --model alias3 --yolo
csi --model alias2-mini

🔒 Sovereign by design

CSI is built so sensitive security work never has to leave your perimeter:

• On-prem & air-gapped — run the suite and alias models cloud-deployed or fully air-gapped, with no dependency on a third-party cloud.
• No data leakage — the harness routes every request through a local proxy and filters non-essential telemetry by default (see Architecture).
• European-built — trained and operated under European data-sovereignty principles.
• Compliance-ready — designed for GDPR and NIS2 obligations.

▶ Default scaffold

When you run csi, it starts using cc — CSI’s security-focused scaffold — out of the box. No extra configuration needed.

csi

⚙ Selecting a different scaffold

Set the CSI_BACKEND environment variable before launching CSI. It is read at startup and determines which AI engine powers the session.

CSI_BACKEND=<scaffold> csi

Available backends

cc is the default scaffold — a security-focused coding agent re-implemented for autonomous cybersecurity work. claude runs Anthropic’s Claude Code. See the cc and Claude Code one-pagers.

★ Which one should I use?

Two questions come up constantly — “is CSI a step down from CAI?” and “do I prompt CSI differently?” The short answers:

• CSI is not a competitor to CAI — it is a meta-scaffold that contains it. CSI is the harness/orchestrator; CAI is one of the scaffolds it can run. Choosing CSI does not mean leaving CAI behind — CSI_BACKEND=cai csi runs the exact same CAI engine, now routed through the CSI proxy.
• Prompting is the same. There is no CSI-specific prompt syntax — you talk to whichever scaffold is behind the wrapper exactly as you would natively. If a session feels weaker, it is almost always the scaffold (and its model), not the prompt. Our prompt guide applies to every backend.
• Use cc as your default. Across our benchmarking, cc and claude are the strongest autonomous-security performers; CAI is fully supported but is one of the lower performers. So if a plain csi session feels more capable than your old CAI runs, that is expected — it is the default cc scaffold doing the work.
• For best results, use them all. CSI’s real advantage is orchestrating several agents at once — mixing scaffolds and models, and having them inspect and correct each other’s work. See Multi-agent.

▶ Launch via CSI

Select Claude Code with CSI_BACKEND (the default scaffold is cc):

CSI_BACKEND=claude csi
CSI_BACKEND=claude csi --model alias1     # pick a model
CSI_BACKEND=claude csi --network host     # share the host network stack

⏩ Continue mode

A CSI convenience: auto-send “continue” when the model stops with end_turn and no tool use, prompting it to keep working.

• Shift+Tab — cycle to ⏩ continue mode on (yellow indicator).
• Environment — CSI_CONTINUE=1 (persists the whole session); cap iterations with CSI_CONTINUE_MAX.

▶ Launch via CSI

csi                          # cc is the default
CSI_BACKEND=cc csi           # the same, explicit
csi --yolo                   # auto-approve tools (long autonomous runs)
csi --model alias3 --yolo

⚙ Built for autonomous security work

Security investigations — port scans, fuzzing campaigns, multi-host triage — generate enormous tool-use traffic, and the number of messages climbs far faster than the token count. cc is built around that reality with a multi-level memory-management system so long sessions keep going where general-purpose agents stall:

• Bounded working set — the hot path avoids unbounded state growth, keeping memory flat across thousands of tool calls.
• Proactive summarization — the conversation is compacted by message count, well before any token limit, preserving investigation context.
• Safety valve — a cheap local fallback keeps the most recent context if a session spikes, instead of crashing.
• Session-memory continuity — transcript and continuity excerpts persist to disk so the agent recovers context after a compaction.

What else cc brings

• Tuned for autonomous --yolo operation, the mode most security workflows run in.
• Agent teams and skill loading for multi-agent investigations.
• Drives CSI dynamic workflows as the default fan-out scaffold.
• Routes any model through the CSI proxy, including the 1M-context endpoints for large-context models.

▶ Launch via CSI

CSI_BACKEND=codex csi
CSI_BACKEND=codex csi --model alias1 "summarise this branch"

What CSI adds

• Responses API ↔ Chat Completions translation in the local proxy — no code changes to Codex.
• Auth handled for you: OPENAI_API_KEY is derived from your Alias API key.
• Single shared JSONL log and cost ledger alongside every other scaffold.
• Quota preflight handling so model switching is seamless.

▶ Launch via CSI

CSI_BACKEND=cai csi
CSI_BACKEND=cai csi --yolo            # auto-approve tool runs
CSI_BACKEND=cai csi --unrestricted    # steering (abliteration)

CAI has its own agent loop, TUI and tool-use system. CSI starts the local routing proxy for unified JSONL logging and cost tracking, and passes the Alias API key via ALIAS_API_KEY.

What you get

• Agent + Runner SDK — from cai.sdk.agents import Agent, Runner.
• 300+ LLMs supported: alias models, Claude, GPT, Gemini, Mistral and local endpoints.
• Interactive /mcp slash commands — the recommended path for MCP workflows.
• Open source — the #1 AI agent for CTFs.

▶ Launch via CSI

CSI_BACKEND=mistral csi
CSI_BACKEND=mistral csi --model alias1 "draft a CHANGELOG"

What you get

• Interactive chat agent with read / write / edit, stateful bash, and ripgrep-backed grep.
• Project-aware context — Vibe scans your file structure and Git status automatically.
• Agent profiles (default, accept-edits, auto-approve, plan) selectable with --agent.
• Programmatic mode (--prompt, --output text|json) for scripting.

▶ Launch via CSI

Run a compiled GCAI scaffold like any other backend:

CSI_BACKEND=gcai csi
CSI_BACKEND=gcai csi --model alias3

♻ The optimization loop

GCAI follows an autoresearch-style loop — the AI agent is the researcher, driving the loop via tool use. One targeted change per iteration, scored by real CTF solve rate (no LLM-as-judge):

• Modify — the agent generates a TypeScript candidate scaffold (one targeted change).
• Compile — esbuild scaffold_candidate.ts → scaffold_candidate.mjs (~35 KB).
• Evaluate — score the candidate on real CTF challenges; the metric is the solve rate.
• Decide — accept if the solve rate improves, otherwise discard; snapshot every iteration.
• Loop — autonomous until convergence, max iterations, or manual stop (--resume to continue).

CSI_BACKEND=cc csi gcai --model opus --target-model alias3 \
    --challenges cybench --max-iters 50 --remote agents

⚙ Host setup (one time only)

These steps are performed once on your host machine before using MCP integrations with CSI.

1. Install dependencies

sudo apt install -y default-jre-headless
curl -LsSf https://astral.sh/uv/install.sh | sh
mkdir -p ~/.csi/burp

2. Configure Burp Suite MCP server

• 1
  Install the extension

  In Burp Suite, go to Extender → BApp Store, search for “MCP Server”, click Install, then Enable.
• 2
  Set host and port

  Leave the defaults: host 127.0.0.1, port 9876.
• 3
  Extract the proxy JAR

  Click Extract server proxy jar (bottom corner of the MCP tab) and save it as ~/.csi/burp/mcp-proxy.jar.

▶ Each session: 3 terminals + inside CAI

Every working session needs three host terminals (Burp bridge, Chrome bridge, CSI) plus the /mcp load commands inside CAI. This workflow uses host.docker.internal from inside the container, which works in every launch mode (bridge or --network host) — the launcher always wires the necessary --add-host.

uvx mcp-proxy --host 0.0.0.0 --port 9878 -- \
    java -jar $HOME/.csi/burp/mcp-proxy.jar \
    --sse-url http://127.0.0.1:9876

uvx mcp-proxy --host 0.0.0.0 --port 9877 -- \
    npx -y chrome-devtools-mcp@latest

CSI_BACKEND=cai csi --model alias1 --yolo

Inside CAI

Once the CSI container is running, load the MCP servers and attach them to the agent:

CAI> /mcp load http://host.docker.internal:9878/sse burp
CAI> /mcp load http://host.docker.internal:9877/sse chrome
CAI> /mcp list
CAI> /mcp add burp redteam_agent
CAI> /mcp add chrome redteam_agent

Smoke test

Verify that the MCP integration is working end-to-end:

CAI> /agent redteam_agent
CAI> Use the chrome MCP to fetch https://example.com and report the page title.

⚙ Optional launcher flags

The host launcher (installed by curl -Ls aliasrobotics.com/get_csi | sh) accepts two optional flags that are parsed before the regular CSI arguments and forwarded to Docker. They are opt-in — leave them out for the default behavior.

CAI .env helper (~/.csi/setup-cai-env.sh)

Created during installation. Useful commands:

Verify inside the container: cat /workspace/.env (should match your repo file when linked). Inside CAI: /env lists CAI_* variables present in the process.

--mount host:container[:ro] — expose host folders

By default, CSI only sees ~/.csi/workspace inside the container. To expose additional paths from your computer, use --mount with the usual Docker bind-mount syntax. The flag can be repeated.

csi --mount ~/Documents/GITLAB:/gitlab
csi --mount ~/projects:/projects --mount ~/data:/data:ro

--network host — share the host’s network stack

By default CSI runs on Docker’s bridge network — fine for most web and MCP workflows (the container reaches host-side services via host.docker.internal). For local-network reconnaissance that needs Layer-2 visibility (ARP scans, live PCAP on your LAN interface, etc.), pass --network host so the container shares the host’s network stack.

csi --network host
CSI_BACKEND=cai csi --network host --yolo
CSI_BACKEND=cai csi --network host --mount ~/Documents/GITLAB:/gitlab

⚙ How to set them

Persist a variable in ~/.csi/config/settings.json (under env) at install time, export it in your shell for a single session, or inline it before the command:

# persisted in settings.json
csi install --api-key sk-xxx --env CLAUDE_CODE_MAX_OUTPUT_TOKENS=16000

# per-session
export CSI_BACKEND=cai
csi

# inline (one run)
CSI_BACKEND=codex CSI_CONTINUE=1 csi "summarise this branch"

▶ Backend & models

⇄ Custom & third-party endpoints

▤ Tuning (Claude Code)

⏱ Rate-limit backoff (all scaffolds)

⏩ Continue mode

⚛ Steering

🔒 Telemetry & updates

☰ Agent view (csi agents)

🔑 Auth (set by the wrapper)

These are normally managed for you by the csi launcher — documented for transparency and advanced overrides.

▶ CAI backend

Loaded from your project .env when CAI starts (see Installation and Launcher flags).

⚙ Environment integration

▶ Alias & provider models

Pick a model with --model (or the ANTHROPIC_MODEL default). Alias models route to the Alias API; Anthropic and OpenAI model slugs route to their providers.

csi --model alias1
csi --model alias3 --yolo
csi --model openrouter/z-ai/glm-5.1 "tell me a joke"

⇄ OpenRouter provider routing

For OpenRouter models, append a :: suffix to control which providers serve the request (maps to OpenRouter’s provider field). Requires OPENROUTER_API_KEY.

openrouter/<provider>/<model>::<key>=<val>[::...]

# pin to a specific provider
csi --model openrouter/z-ai/glm-5.1:::provider=z-ai,z-ai::only=z-ai

# exclude Azure, prefer fp8 quantization
csi --model openrouter/meta-llama/llama-4-maverick::ignore=Azure::quant=fp8

▤ Custom, local & remote endpoints

Point CSI_CUSTOM_ENDPOINT at any OpenAI-compatible server (vLLM, TGI, Ollama, llama.cpp, a remote host). The proxy translates the scaffold’s wire format to Chat Completions and forwards the system prompt verbatim. Set CSI_CUSTOM_API_KEY if the endpoint needs auth.

# a locally served GGUF model with native tool calling
CSI_CUSTOM_ENDPOINT=http://localhost:5050 csi --model qwen3-8b --no-banner "tell me a joke"

# a remote vLLM / SGLang server
CSI_CUSTOM_ENDPOINT=http://10.0.0.5:8000/v1 csi --model Qwen3.5-27B --no-banner "tell me a joke"

# drive it from any scaffold
CSI_BACKEND=cc CSI_CUSTOM_ENDPOINT=http://10.0.0.5:8000/v1 csi --model Qwen3.5-27B --yolo

▶ Telegram

• 1
  Create a bot

  Message @BotFather, run /newbot, and copy the token.
• 2
  Add the token

  Globally in settings.json, or per-agent in frontmatter.
• 3
  Bind an agent

  Add a channel: { type: telegram } block to the agent.
• 4
  Launch

  Reinstall, then run csi with the agent.

Global token in ~/.csi/config/settings.json:

{ "channels": { "telegram": { "botToken": "123456:ABC-DEF..." } } }

Agent with a channel binding (plugins/csi/agents/mybot.md):

---
name: mybot
description: "My Telegram bot"
model: alias1
channel:
  type: telegram
  # botToken: "123456:ABC..."   # optional per-agent override
permissionMode: bypassPermissions
---
Your agent system prompt here.

csi --model alias1 --agent csi:mybot --no-banner --yolo

▶ Google Chat

• 1
  Enable the API

  In Google Cloud Console, create a project and enable the Google Chat API.
• 2
  Service account

  Create one and download the JSON key file.
• 3
  Webhook URL

  Point the Chat app at https://<tunnel>/webhooks/googlechat (use ngrok / cloudflared for localhost).
• 4
  Bind & launch

  Add channel: { type: googlechat } to an agent, reinstall, and the webhook is served by the proxy.

Global config in ~/.csi/config/settings.json:

{
  "channels": {
    "googlechat": {
      "serviceAccountFile": "/path/to/service-account.json",
      "audienceType": "project-number",
      "audience": "123456789"
    }
  }
}

▶ Run one

No script needed — describe it in natural language and CSI parses the topic, agent counts and scaffolds:

# one agent per scaffold, each a different model
csi agents workflow "pentest aliasrobotics.com, an agent per scaffold, each a different model"

# 10 agents on the default scaffold
csi agents workflow "compare TLS vs SSH, 10 agents"

# explicit fan-out
csi agents workflow fanout "<topic>" --scaffold cc,cai --per-scaffold 2 --model alias2-mini

# run or resume an explicit script
csi agents workflow run path/to/flow.js [--args '<json>'] [--resume <runId>]
csi agents workflow list | stop <runId>

You can also launch one straight from the csi agents TUI prompt: typing workflow … highlights the keyword and dispatches a fan-out detached, so the group appears in the roster as its agents come up.

⚙ How it works

A plain-English request becomes a deterministic script through a three-layer interpretation ladder (first usable result wins). Whatever the layer, the output is the same artifact — a JS workflow script under ~/.csi/workflows/<runId>/ — so every run is inspectable, editable and --resume-able.

The engine runs the script in a sandbox with phase(), parallel(), pipeline(), agent(), budget and log() primitives, plus a content-addressed journal for resume. Each agent() crosses a single dispatch seam into the fleet — a real tmux job on any scaffold (cc, claude, codex, cai, gcai, vibe) — and a final synthesis agent integrates every view, citing each agent’s transcript.

  csi agents workflow "pentest target.com, an agent per scaffold"
                       |
   (1) INTERPRETATION LADDER     L1 author / L2 plan / L3 regex
                       |   ->  workflow.js  (~/.csi/workflows/<runId>, resumable)
   (2) ENGINE (node:vm sandbox)  phase . parallel . pipeline . agent . budget
                       |   agent(prompt, { scaffold, model })   <- the host seam
   (3) DISPATCH SEAM             each agent() -> a real tmux fleet job, live in
                       |          csi agents:  cc . claude . codex . cai . gcai . vibe
                       v
              SYNTHESIS agent  -> integrates every view, cites each transcript

⚙ The agent roster (csi agents)

One TUI dispatches, monitors, attaches to, replies to and stops background sessions across every scaffold. Each job is routed through the shared proxy, so a single model identifier reaches the right upstream from whichever scaffold dispatched it.

# open the cross-scaffold roster
csi agents

# one-shot dispatch (fire and forget) on the default scaffold (cc)
csi agents "investigate the flaky auth flow on 10.0.0.5"

# dispatch on a specific scaffold
CSI_BACKEND=cai   csi agents "enumerate SMB shares on 10.0.0.5"
CSI_BACKEND=codex csi agents "summarise the findings so far"

The roster shows each agent’s jobId, its scaffold@model, and live state (working / done / blocked / failed). Full architecture is on the Architecture page.

❖ Mix agents — and have them correct each other

Because every agent is addressable by jobId, a new prompt can build directly on a previous agent’s work — including across scaffolds. Reference a prior agent with @<jobId> and CSI injects that agent’s last output and transcript pointer into the new prompt:

# have a cc agent review and correct what a CAI agent produced
csi agents "@a05738af review this exploit for false positives and fix it"

# ask a fresh agent to get inspired by an earlier one's recon
csi agents "using @a05738af's port scan, propose three privilege-escalation paths"

This is the recommended way to work: let several agents tackle the same target from different angles, then point one at another’s output to verify, refine or cross-check it.

♻ Collaboration modes

For a coordinated team rather than independent jobs, group agents and pick a shared-memory mechanism. The default is a Blackboard: a shared append-log (a trusted notes.md plus a suggestive hypotheses.md) that members read and write as they progress, so the group converges instead of duplicating work.

# a 4-scaffold team sharing a blackboard
csi agents --scaffold claude,codex,gcai,cai --group bb --collab blackboard \
  "pentest staging.example.com (in-scope only); coordinate via the blackboard"

Other mechanisms (scratchpad, topic, mailbox, verify) trade off how tightly members coordinate. For deterministic, script-driven fan-out and synthesis, use Dynamic workflows instead — CSI plans the fan-out, runs an agent per scaffold/model and synthesises every view into one cited answer.

♻ Compaction

Compaction summarises the older part of a conversation so a long session keeps running without overflowing the model’s context window. It works across all supported scaffolds. Most of the time it is automatic — CSI compacts proactively as the context fills and recovers transparently from an over-length request — but you can also trigger it yourself:

/compact

⏱ Rate limits & timeouts

When requests start getting throttled, nothing is broken — this is the deliberate per-key rate limiting that comes with PRO licenses. It exists so that individual keys do not oversaturate our shared inference servers.

• What you see: requests are slowed or temporarily rejected (HTTP 429, or a 5xx overload) once your key’s quota for the moment is reached.
• Recovery: once the limit is hit, it takes roughly 3–5 minutes for our servers to start accepting requests from a saturated key again. Waiting it out is enough — no reinstall or restart needed.
• Automatic backoff: the CSI proxy now rides out the whole cooldown for you. It retries throttled (429) and overloaded (5xx) requests with a true exponential backoff — 2s, 4s, 8s, 16s, then capped at 30s — honoring any Retry-After the server sends, for up to ~5.5 minutes total before surfacing an error. So the current action resumes on its own once the window clears, rather than failing the turn.

💾 Accessing logs (and getting them out of Docker)

Every session is logged as .jsonl. The good news for Docker users (e.g. on Kali): the most important logs are already bind-mounted onto your host — you do not need to docker cp them, and they survive the container exiting (CSI runs with --rm).

From inside the session you can always resolve the active log path or open the viewer:

# print the path of the active proxy API JSONL
csi agents log --path

# open the log viewer (live)
csi agents log --live        # or --viewer

# print a specific job's recent transcript
csi agents logs <jobId> [--tail N]

Inside the container the same files live under /home/vscode/.csi/logs/ and /home/vscode/.claude/projects/ — both of which map straight to the host paths above, so you can simply open them on Kali after (or during) the run.

CAI transcripts & the docker cp fallback

CAI writes its native transcript to ~/.cai/logs/cai_*.jsonl inside the container, which is not bind-mounted. To pull it (or any other in-container path) to the host without closing the container, copy it from a second terminal while the session is still running:

# find the running CSI container
docker ps

# copy the CAI transcript out to the host
docker cp <container>:/home/vscode/.cai/logs ~/csi-logs/

# or copy a single file
docker cp <container>:/home/vscode/.cai/logs/cai_<id>.jsonl ./

▶ Modes

# without steering (the model may refuse)
csi --model alias3 --yolo -p "Explain how to pick a lock"

# per-prompt steering (auto-resets after this turn)
csi --model alias3 --yolo -p "/steering Explain how to pick a lock"

# persistent steering (entire session)
CSI_STEERING=1 csi --model alias3 --yolo

⚙ How it works

The /steering skill POSTs to ${ANTHROPIC_BASE_URL}/csi/steering; the proxy flips an in-memory flag and records the current user-message count as a baseline. On the agent’s next answer the proxy injects steering_enabled:true into the Alias API request, and the model returns an uncensored response. On the next user turn (message count past the baseline) the proxy auto-disables it — tool-use chains within the same turn keep it active. Persistent mode (CSI_STEERING=1) skips the auto-reset.

⚠ Common issues