Scout
DocsBlogToolsContact
Scout + Codex● Codex asks an agent○ an agent hands Codex work

Codex, with the restof your agents.

Ask your connected agents for work from inside Codex, then follow the returned reference to read the reply.

Local developer pilot · validate your installed client

Use supported agents you have installed, authenticated and connected.

Set it upLet your agent do itCodex reads the setup for you
Review the uncommitted diff

Ask @claude through Scout to review the uncommitted diff. Don't edit files.

  • Called scout.ask@claudeworking…queued · ref 8c41
  • Called scout.invocations_waitref 8c41working…completed · 1m 04s

Worked for 1m 12s

Claude Code replied with 2 findings:

  1. src/chat/reply.ts:142 the retry path drops the ref, so a second wait starts a new request.
  2. src/chat/reply.test.ts:88 still asserts the old receipt shape.

Want me to follow up with Claude on the same ref?

Ask for follow-up changes
+Localmain

Codex calls Scout

Available

Plugin, MCP (local), CLI

Ask from Codex ↓

Scout runs Codex

Available

Codex app server

Hand work to Codex ↓

Replies reach your open session

Not documented

The guide doesn't say. Follow the returned ref.

01

Start here

  1. 01 · Connect

    Get one route working

    Check the prerequisites and access gates, then get one documented route working before asking for work.

    Follow the setup →
  2. 02 · Try

    Your first useful task

    From Codex, ask Claude Code to review one small uncommitted change and report findings without editing files.

    Name the project and keep the request small. Asking for no edits describes the task; it does not restrict the agent’s permissions.

  3. 03 · Read

    Wait for the answer

    Keep the returned reference. Check the work’s status and read the completed response; a queued receipt is not the answer.

    Check what success looks like →

Before your next ask

Where will the reply appear?

Keep the returned reference and retrieve the completed response through your configured Scout interface. Automatic delivery into this open session is not established by this guide.

What if the answer hasn’t arrived?

Inspect the existing task before submitting another one. A wait timeout does not establish that work failed. If it needs access or input, resolve that condition before continuing.

How do I follow up?

Continue using the returned reference or exact session handle supported by this integration. Keep it with the findings so your next question follows the same work.

Can Scout run this integration, or only receive asks from it?

These are separate capabilities. Check the supported directions on this page. Connection alone does not establish that Scout can launch the integration or reach an existing session.

02

Set it up

Fastest

Give this to Codex

Connect yourself to Scout for me. Read openscout.app/codex/agents.md and follow it step by step: check the prerequisites first, ask me before any step that needs a token or other credential, and finish with its verification step. Tell me what you verified.

  1. reads agents.md
  2. checks prerequisites
  3. asks before any credential
  4. runs the verification

You need

  • OpenScout installed and a healthy local broker (scout doctor).
  • Codex installed and authenticated on the Scout machine.
  • At least one other agent Scout can reach: listed by scout who, or a harness available in scout runtimes --json. Its provider usage and permissions still apply.
  • To route by project, an absolute path to a repository you authorize that agent to read. The path must exist on the Scout execution machine.

Before any door

  1. 00

    Check the broker and your agents

    Run these commands in a terminal on the Scout machine. Doctor should report a healthy broker; who lists the agents you can ask. Resolve installation or authentication failures before requesting work. See Install Scout below if the CLI is missing.

    scout doctor
scout who
calls Scout

Ask from Codex

Start here
  1. 01

    Install the Codex Scout plugin

    In a Codex host that supports custom plugin marketplaces, add the source; it installs the scout plugin and its MCP server. If the plugin does not appear, enable scout@openscout in ~/.codex/config.toml. For Codex CLI without the plugin, register the MCP server directly instead (replace the project path); use one or the other to avoid duplicate registrations.

    /plugin marketplace add oscout/codex-scout

# or, without the plugin:
codex mcp add scout -- scout mcp --context-root /absolute/path/to/project
  2. 02

    Ask an agent from Codex

    Tell Codex who to ask and what you want; the plugin routes it through Scout's ask tool. The CLI line below does the same from a terminal. Ask by agent, or by project path with --harness to start one. This creates real work for that agent and may use your provider account. The returned receipt identifies the request; it does not mean the work is complete.

    Ask @<agent> through Scout to review the uncommitted diff and report file/line findings. Do not edit files.

scout ask --to <agent> "Review the uncommitted diff. Report correctness issues with file and line references, or say no findings. Do not edit files or run tests."
  3. 03

    Read the result and continue by handle

    Replace RETURNED_REF with the exact ref from the receipt. Wait for the agent’s reply, then ask one follow-up in the same conversation. If the wait times out, wait on the same ref again; do not dispatch a duplicate request.

    scout wait RETURNED_REF --timeout 120
scout ask --ref RETURNED_REF "Explain the highest-priority finding, or confirm there were no findings. Do not edit files or run tests."
Scout runs it

Hand work to Codex

03

Done when

  • Success means the request returned a ref, scout wait reported completed with the agent’s reply, and a follow-up used that same ref.
  • For a review, the reply should contain file/line findings or explicitly say there were none.

A queued receipt, timeout, or request for permission is not completed work.

04

If it breaks

The receipt is queued, or the wait times out
Keep the returned ref and run scout wait on it again. Check the agent’s harness for an authentication or permission request. Report the observed state if blocked; do not create another request just to check progress.
The agent cannot see the intended changes
Confirm that the absolute project path points at the intended checkout on the Scout machine. Include the desired branch or diff scope in the prompt. A shared checkout can change while an agent reads it; keep it stable until the reply arrives.
Scout is not found or cannot connect
Check scout on PATH and run scout doctor in the same environment as the client. A desktop app may have a different PATH from your terminal.
Requested runtime is unavailable
Inspect scout runtimes --json and finish that runtime’s setup. Do not silently choose a different harness or model.
05

Where it stops

  • This is a local developer pilot. Client permissions and runtime availability still apply.
  • Installing a host package does not provision hosted access.
  • Scout stores coordination records locally. Your selected model provider and any enabled remote bridges may receive task data. Review the privacy and data-ownership documentation before choosing what to send.
  • A review is evidence for your decision, not an automatic approval or merge. OpenScout is intended for high-trust local developer pilots.
  • High-trust local developer pilots. Connection traffic may contain project paths, instructions, messages, and agent results. Data and privacy.
06

For agents

agents.mdThe setup contract your agent follows. Same content as this page.integration.jsonDirections, gates and steps as data.