Claude Code and Grok: connect your coding agents

Yes: Claude Code and Grok can exchange requests and results through Scout. Start from Claude Code, Grok CLI, or a connected host, name the project and the question, then keep the returned handle to read the answer and continue. Each agent keeps its own session and permissions; the request supplies the context the other participant needs.

Choose the connection you actually need

If Scout is new to you, start with the quickstart. For transport configuration and troubleshooting, keep the Grok connection reference alongside this workflow.

Any agent can propose an approach, ask a question, make a change, or review another agent's work. The example below follows a hypothetical webhook retry change through investigation, implementation, and critique. Those are temporary assignments you can swap. It is an illustrative workflow, not a measured past result.

How the connection actually works

Claude Code and Grok can be peers while exposing different control surfaces. For Claude, the choices include an interactive terminal and a structured programmatic CLI. Scout supports a tmux path and a stream-JSON adapter. The listed Grok CLI route, grok-acp, uses Agent Client Protocol over a managed process. These are transport choices; either participant can initiate a useful question or propose a change.

Track three pieces separately: the native session receiving the message, the Scout reference tracking the request, and the artifact returned. A terminal accepting text is weaker evidence than a structured completed-turn result. A permission prompt needs an attention path, even when the request itself arrived successfully.

A Grok model running inside another coding tool uses that tool's interface. Hosted Grok Bot uses its connector path instead. Choosing the name “Grok” does not select one universal session API. Grok Build↗, Claude programmatic interface↗.

For the component-by-component explanation, see the collaboration mechanism guide. The example below temporarily assigns tasks to make the exchange concrete; you can swap the participants.

What must be ready

Install and authenticate the Claude Code and Grok runtimes you intend to use. Initialize Scout using the quickstart, then check the broker and runtime configuration:

The destination needs access to the project checkout and any documents supplied in the request. Research also needs a working browsing tool or supplied source material. Selecting Grok alone does not prove that web search is available in that particular session.

Follow Claude Code setup and Grok setup for the installed routes. Scout supports high-trust developer pilots. Its local broker records coordination; the selected model provider still receives the prompt and context required for the work.

Grok CLI and Grok Bot are different paths

Grok can refer to a model, the Grok CLI coding agent, or Grok Bot, xAI's hosted agent product. Decide which environment should execute the task before connecting it.

The Scout for Grok documentation explains these paths. Adding a hosted connector does not install a local runtime or create the bridge. xAI also publishes Grok CLI package instructions↗. Check the runtime you actually have; model identity and execution environment are separate facts.

1. Give research an answerable question

“Research webhooks” is too broad to hand directly into implementation. For the retry example, ask a question with a decision attached: under which conditions can this application retry delivery without processing an event twice?

Prepare this brief, replacing the project and artifact paths with real locations the receiving agent can access:

Goal: recommend a retry policy for this application's webhook delivery.
Checkout: /absolute/path/to/project
Inputs: delivery code, existing tests, and the provider's official docs.
Questions:
- Which responses should trigger retry?
- How is a duplicate event identified?
- Can the provider deliver events out of order?
Constraints: preserve the public API; do not edit application code.
Return: a concise recommendation, source URLs, relevant repository paths,
unsupported assumptions, and questions requiring a product decision.
Artifact: /absolute/path/to/research-note.md
If browsing is unavailable: say so; use supplied sources without claiming
that they were checked against current documentation.

Fill in the real paths and save the brief as a UTF-8 file. Replace the two example paths below; --prompt-file sends that file’s contents as the request:

Use the Grok route shown by your installed scout runtimes; this example uses grok-acp. A project route resolves or starts a worker. It does not necessarily address the Grok conversation already open elsewhere. The receipt prints a flight id and, when the broker binds one, a ref: handle. Keep that handle as the research work reference.

2. Review the evidence before implementing

Use the returned ref: handle in place of ref:RESEARCH:

If continuation returns an ambiguous-session error, use the exact route supplied by the broker after checking its identity. A timeout without a receipt leaves execution unconfirmed: inspect existing work before trying again.

An accepted request may still be queued or running. A wait timeout ends only the wait; it does not cancel or fail the work. Wait on the same handle again rather than launch a duplicate investigation.

Read the artifact. A source can establish a provider guarantee, but it cannot establish that your code obeys it. A claim about duplicate detection needs a repository location; a claim about delivery order needs a relevant provider source. Keep unresolved assumptions visible in the implementation brief.

3. Ask Claude Code to implement the accepted decision

Write a second brief after assessing the research. For example, the accepted decision might require retrying a defined set of transient failures and preserving a stable event identifier. Those are illustrative requirements; use the guarantees established for your actual provider.

Include the research artifact, approved requirements, allowed files, compatibility constraints, and the checks you authorize. Give the worker an owned checkout. Record its starting revision so the returned change can be reviewed precisely.

Save this request's separate reference. The research conversation and implementation conversation now have different jobs and different return paths. Passing a file path is useful only if the destination can actually read that file; across machines, explicitly transfer the artifact and supply its destination path.

Claude Code has its own subagents↗ for bounded tasks inside one session, and cross-session messaging↗ between Claude Code sessions. Neither reaches Grok. A separate Grok handoff creates another execution context, so include the necessary evidence explicitly.

4. Return the implementation for critique

Once Claude reports its result, inspect it and freeze the review target. Prefer a base and head commit over a moving branch name. Ask Grok to compare that revision with the accepted requirements:

Replace all placeholders, then wait using this critique’s new receipt. Confirm that the referenced checkout contains both commits. Returning to the research thread preserves continuity, but it does not give Grok automatic access to Claude's transcript or updated files.

If a finding is unclear, ask for the precise sequence of events that would trigger it. An agent's confidence is less useful than a concrete failure condition you can assess.

How the connection actually works

Claude Code and Grok can be peers while exposing different control surfaces. For Claude, the choices include an interactive terminal and a structured programmatic CLI. Scout supports a tmux path and a stream-JSON adapter. The listed Grok CLI route, grok-acp, uses Agent Client Protocol over a managed process. These are transport choices; either participant can initiate a useful question or propose a change.

Track three pieces separately: the native session receiving the message, the Scout reference tracking the request, and the artifact returned. A terminal accepting text is weaker evidence than a structured completed-turn result. A permission prompt needs an attention path, even when the request itself arrived successfully.

A Grok model running inside another coding tool uses that tool's interface. Hosted Grok Bot uses its connector path instead. Choosing the name “Grok” does not select one universal session API. Grok Build↗, Claude programmatic interface↗.

For the component-by-component explanation, see the collaboration mechanism guide. The workflow above assigns tasks to make the exchange concrete; you can swap the participants.

Reverse the roles when the context calls for it

Claude Code can investigate repository behavior and send Grok a scoped implementation task. Grok can then return a revision for Claude to review. Keep the same agreement: each step has an owner, inputs, allowed actions, a result artifact, and a saved reference.

Avoid two workers silently fixing the same review finding. Have one implement the accepted correction and the other assess the new revision. Separate worktrees help with file ownership; shared ports, databases, and external services still need explicit coordination.

If the handoff gets stuck

Can I use my existing Grok conversation or subscription?

A project-and-harness request selects a worker for that project; it does not automatically attach to a Grok chat open in your browser. Continue Scout-routed work with its returned reference. To call local agents from hosted Grok Bot, use the hosted connector and bridge setup.

The selected runtime uses its configured provider account. Check that account’s access and billing for the execution route you choose; having a chat subscription alone does not establish that a CLI or API route is covered.

What a completed collaboration looks like

A useful result contains the researched decision, the implemented revision, review findings and their disposition, and the checks actually performed. An acknowledgment, an artifact path without readable content, or two agents agreeing is insufficient evidence by itself.

Start with one question and one reviewable change. Set up Claude Code and Grok, then use the same handoff discipline for other peers. The Claude Code and Codex review workflow provides another concrete pairing; the collaboration guide explains when to expand beyond two agents.