Starlight methods are written for the coding agent you already use. This page shows how the same move looks across six coding agents so you can switch harnesses or run cross-provider reviews without relearning the CLI flags.

## Run a task headlessly [#run-a-task-headlessly]

| Agent & tested version | Headless command | Flag to allow file edits |
|---|---|---|
| **Claude Code `2.1.303`** | `claude -p "<task>"` | Set a permission mode, or approve edits interactively |
| **Codex `0.163.0`** | `codex exec "<task>"` | `-s workspace-write` |
| **Gemini CLI `0.60.0`** | `gemini -p "<task>"` | `--approval-mode auto_edit` |
| **Antigravity `1.4.2`** | `agy -p "<task>"` | `--mode accept-edits` |
| **Grok `1.0.62`** | `grok -p "<task>"` | `--permission-mode acceptEdits` |
| **OpenCode `2.0.32`** | `opencode run "<task>"` | Configured via permission settings |

> **Measured sandbox behaviour (checked 2026-10-20):** Codex in `exec` mode cannot write outside its working folder unless granted via `--add-dir`, and on Windows its default sandbox blocks `git push`. Grok with `--permission-mode plan` or `dontAsk` answers in a single turn without making tool calls, so headless file review requires default or `acceptEdits` mode.

## Connect the Starlight MCP tools [#connect-the-starlight-mcp-tools]

| Agent | Command to add the public MCP endpoint |
|---|---|
| **Claude Code** | `claude mcp add --transport http starlight https://starlightintelligence.ai/mcp` |
| **Codex** | `codex mcp add starlight --url https://starlightintelligence.ai/mcp` |
| **Gemini CLI** | `gemini mcp add --transport http starlight https://starlightintelligence.ai/mcp` |
| **Grok** | `grok mcp add starlight https://starlightintelligence.ai/mcp` |

See the [quickstart](/starlight/quickstart) for scope options and for connecting the `/api/mcp` documentation server.

## Maker vs. checker: give one task to two different providers [#maker-vs-checker-give-one-task-to-two-different-providers]

The single highest-leverage habit in multi-agent engineering: **the agent that wrote a change must never be the agent that approves it**. Write with one harness, then verify with a second harness from a different model family so they do not share correlated blind spots.

```bash
# 1. Maker pass (Claude Code)
claude -p "Write unit tests for src/auth and fix any failing cases"

# 2. Independent verifier pass (Codex, read-only sandbox)
codex exec -s read-only "Review git diff as a skeptical senior engineer. List concrete defects only."
```