# Evidence and scope

This resource compares commit-pinned source checkouts. Codex, pi, and Goose were inspected on **18 October 2026**; Sidekick was added on **19 October 2026**. It explains implementation choices; it does not rank products or measure task-solving quality.

| Harness | Repository | Inspected commit |
| --- | --- | --- |
| Codex | [openai/codex](https://github.com/openai/codex) | `8c076942cb70fba8e5c4732c23f1faabc4aed484` |
| pi | [earendil-works/pi](https://github.com/earendil-works/pi) | `482c1381a00d8d00bc81697e4a980c593db6803e` |
| Goose | [aaif-goose/goose](https://github.com/aaif-goose/goose) | `34a222e3f2b95d8b4a43482b53c2cc957ecce26d` |
| Sidekick | [datex/sidekick](https://github.com/datex/sidekick) — private | `463d653124e1c2cda46a3f14f01f3d6f384326b1` |

Sidekick was reviewed from the supplied local checkout. Its source links require repository access; public readers may receive a GitHub 404. This guide publishes explanations and citations, not a copy of its private source. Its native model/tool runtime and its Outpost adapters for external agents are assessed separately. Hosting another harness does not establish that harness's capabilities as native Sidekick behavior.

These are source snapshots, not an assertion about the latest published release. A feature present in a checkout may be unreleased, optional, experimental, or used only by a particular frontend.

## How the research was done

Research agents investigated the repositories using local source, documentation, and test definitions. Sidekick's review was divided across execution, coordination, and tool/provider boundaries. The coordinating agent synthesized a common vocabulary and compared the findings. Each chapter contains an evidence matrix and a source reading path. Structured feature records power the website's comparison table.

Implementation claims link to immutable GitHub commit URLs, usually with line anchors and named symbols. Repository documentation explains intended behavior; implementation code establishes the paths inspected; test code provides evidence of intended invariants. Reading a test is not the same as running it.

The example repair traces and interactive walkthrough are educational simulations. They do not call the harnesses, execute tools, or report observed performance. The builder's exercises describe a proposed runtime, not a single design shared by all four projects.

## How to read support labels

| Label | Interpretation |
| --- | --- |
| Core | Implemented in the primary runtime or documented baseline under discussion. This does not mean enabled in every configuration. |
| Optional | A flag, setting, extension, build feature, or deployment choice is needed. |
| Library | A separate reusable package provides primitives; the default application may not use them. |
| Example | Supplied as an example or pattern, rather than a built-in workflow. |
| Partial | The inspected implementation covers part of the capability; read the qualification. |
| Unknown | Not established in the inspected scope. This is not proof of absence. |

These labels are descriptions, not scores. A cell can span several layers, so its text and citations take precedence over its compact label. For example, a library can support replicated state without its terminal application providing a collaborative workspace.

## Fair comparison rules

Compare the same boundary: model request with model request, persisted session with persisted session, and application-level policy with application-level policy. Do not equate permission prompts with operating-system isolation, MCP support with arbitrary MCP server safety, or saved history with exactly-once execution.

Separate the reusable runtime from its application shell. Codex's public repository does not establish every proprietary desktop or hosted-service behavior. Pi's newer packages do not automatically describe the coding-agent's default runtime. Goose's shared state machine and application-specific operations are different layers.

Negative findings are bounded to the inspected code paths. “No full collaborative room established” means the research found specific sharing primitives without establishing the complete product; it does not claim such a product cannot be built.

## Limits

The research did not run the harnesses against live providers or execute their full test suites. It did not audit every tool implementation, platform-specific sandbox, extension, or deployment. It provides no latency, cost, reliability, or model-quality rankings. Website checks are separate from harness validation and are recorded in the project's verification report.

Source behavior can depend on flags, policy, model capabilities, frontend, and environment. For decisions that depend on one setting or deployment, follow the linked code and add a focused runtime test in that environment.

## Revisit with new evidence

Keep old snapshots intact. Add a new commit-pinned chapter and fact set, check changes along the same comparison axes, and document whether a difference is a real behavior change, a newly discovered fact, or a correction to this guide. See [the maintenance workflow](../MAINTAINING.md).