# Radar Runtime Capability Matrix

Purpose: map what `ccd-radar` can rely on across supported runtimes as of 2026-03-07.

Method: this matrix only uses official docs reviewed during the session. `No documented support found` means the official docs reviewed did not describe that capability; it is not proof that the capability is impossible.

## Matrix

| Runtime | Documented native approval UI | Documented reusable approval | Documented native UI for arbitrary skill-authored questions | Other documented integration surface | CCD implication |
|---|---|---|---|---|---|
| Codex | Yes. The CLI has approval modes, and in Suggest mode it requires approval before making changes or executing commands. The docs also say to review outputs and approve, reject, or tweak them. | Partial. The official getting-started page documents approval modes, but the docs reviewed do not clearly document a skill-triggerable `approve and reuse` choice. | No documented support found in the docs reviewed. | Codex documents MCP support shared between the CLI and IDE extension. | Use native approvals for tool and file actions the runtime already mediates. Do not assume a skill can create a new approval widget for arbitrary Radar questions. |
| Claude Code | Yes. Claude Code documents `ask`, `allow`, and `deny` permission rules plus permission modes. | Yes. Anthropic documents `Yes, don't ask again` behavior for bash commands and file modification lifetimes. | No documented support found in the docs reviewed. | Claude Code documents settings, `/permissions`, subagents, and hooks. | Repo-local skill text can align the decision flow, but native approval UI is governed by Claude Code's permission system, not by the skill text itself. |
| Gemini CLI | Yes. Gemini CLI documents confirmation for sensitive tool operations and a trust dialog for folders. | Partial to yes. Gemini docs show `Yes, allow always` in IDE integration and describe confirmation for sensitive tools. | No documented support found in the docs reviewed. | Gemini CLI documents headless mode with JSON output. | Gemini can likely support runtime-native approval steps for tool actions, but richer Radar UI still needs either runtime support or an adapter beyond plain skill prose. |
| OpenCode | Yes. OpenCode documents `ask`, `allow`, and `deny` permissions, and the approval UI offers `once`, `always`, and `reject`. | Yes. `always` approves future matching requests for the rest of the current session. | No documented support found in the docs reviewed. `skill` permission covers loading a skill, not arbitrary per-question UI. | OpenCode documents non-interactive `run`, `serve`, MCP, and a configurable permission system. | OpenCode already exposes a close match to the Radar approval semantics, but arbitrary skill-authored Radar questions still need either runtime support or a dedicated adapter. |

## Structured question / multi-select support (as of 2026-03-07)

| Runtime | Structured question tool | Multi-select | Status | Source |
|---|---|---|---|---|
| Claude Code | `AskUserQuestion` | Yes (`multiSelect: true`) | Shipped | SDK tool docs |
| Codex | `ask_user_question` (proposed) | Yes (proposed) | Open — [issue #9926](https://github.com/openai/codex/issues/9926), PR #9904 | GitHub |
| Gemini CLI | None documented | Plan-mode multi-select only | No general-purpose tool | Release notes v0.32.1 |
| OpenCode | None documented | No | — | Docs reviewed |

**CCD implication:** `ccd-radar` instructs agents to use native multi-select for the recommendation checklist. On runtimes without multi-select, the fallback is a numbered list with `Which numbers to apply? (default: all)` — one text interaction instead of separate yes/no questions per bucket.

## Practical CCD contract

- Standardize approval intent across runtimes, not widget shape.
- The shared approval intents are:
  - `approve`
  - `approve and reuse when the runtime supports sticky or session-scoped approvals`
  - `reject and explain`
- Skill text can request native multi-select and single-select UI, but it cannot force a runtime to render it. Use the shortest clear text fallback when the runtime lacks support.
- Radar recommendations are presented as a single batch checklist, not separate sequential questions.

## Why the CLI still matters

- A runtime-neutral CLI schema can carry Radar evaluation state without relying on prose parsing.
- Version the schema and keep approval-step evidence local so runtime adapters can render each decision without reconstructing it from multiple prose sections.
- Runtime UIs can render native approval affordances from structured Radar data once a stable JSON contract exists.
- Platform-specific adapters should come later, after the shared Radar schema and approval contract stabilize.

## Planned follow-up in this repo

- Main backlog item `24` is now grounded by the initial `ccd handover` surface. The next step is to refine that JSON contract so runtimes can consume richer shared machine-readable data instead of reparsing prose prompts.
- Radar item `25` intentionally parks runtime-specific adapters until the shared schema is shipped and daily use shows that platform glue is still necessary.

## Sources

- Codex:
  - https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started
  - https://platform.openai.com/docs/docs-mcp
- Claude Code:
  - https://docs.anthropic.com/en/docs/claude-code/settings
  - https://docs.anthropic.com/en/docs/claude-code/team
- Gemini CLI:
  - https://google-gemini.github.io/gemini-cli/docs/tools/
  - https://google-gemini.github.io/gemini-cli/docs/ide-integration.html
  - https://google-gemini.github.io/gemini-cli/docs/cli/trusted-folders.html
  - https://google-gemini.github.io/gemini-cli/docs/cli/headless.html
- OpenCode:
  - https://opencode.ai/docs/permissions/
  - https://opencode.ai/docs/agents/
  - https://opencode.ai/docs/cli/
