# Plugin harvest targets for the coder

**Date:** 2026-08-25

**Status:** Survey and backlog. Nothing here is committed work until it has an

issue and a Gym delta.

**Method:** direct reading of the reconstructed Grok CLI Rust workspace — the

`grok-build` clone in the workspace's external reference area,

`projects/repos/grok-build`, about 80 crates under `crates/codegen/` —,

the teardown of that codebase in the `openagents` monorepo

(`docs/teardowns/2026-07-15-grok-build-teardown.md`), the plugin model

assessment (`docs/2026-08-24-triage-and-plugin-model-assessment.md`), the

tool zero-base audit (`docs/2026-08-23-agent-tools-zero-base.md`), and the

Harbor Terminal-Bench plan (`docs/2026-08-24-harbor-terminal-bench-plan.md`).

## Why this document exists

The first two working coder plugins — `foreign_sessions` and

`read_conversation`, both live in the capability catalog today — were

harvested from Grok's session lineage: Grok ships `xai-grok-active-sessions`

and `xai-grok-session-search` crates for exactly the discover-and-read work

we rebuilt as sandboxed WASM guests. The harvest worked: one spoken request

in `openagents coder` now discovers, digest-verifies, loads, and runs both

plugins with no improvised shell in the loop.

Grok's workspace holds more of the same shape. This document names the next

targets, ties each to the Terminal-Bench task classes the Gym grades the

coder on, and says what each needs from the plugin host. The Gym rule from

the Harbor plan applies to every entry: a plugin lands with a before-and-after

suite score on the same recipe, and its ATIF-stamped `tool.ran` steps make

the delta attributable to the exact digest. A plugin that moves no score is

questioned.

## What makes a good harvest

The plugin model admits a narrow shape, on purpose:

- **Read-only or pure.** The sandbox grants read-only mounts and nothing

  else. Edits, writes, and process execution stay in the coder's core tools,

  where the permission profile governs them.

- **One-shot and bounded.** One packet in, one packet out, under a time and

  memory bound. Daemons, watchers, and anything that must outlive a call

  (`xai-fsnotify`, background tasks) do not fit until the host grows a

  lifecycle for them.

- **Typed and honest.** Input and output schemas in the manifest, and output

  that names its own truncation the way `read_conversation` reports

  `tail_only` and `dropped_leading_turns`.

- **Worth a catalog line.** The capability tool carries each installed

  plugin's name and first sentence in its standing description, capped at

  twelve. A plugin competes for that space with everything else installed.

Grok links these capabilities into one native process. We deliberately do

not: the WASM boundary is what makes a harvested capability reviewable,

priceable, and safe to auto-approve from a digest-pinned catalog.

## Targets from the Grok workspace

Ordered by expected Gym delta per unit of work.

### 1. `repo_map` — the codebase graph

**Source:** `xai-codebase-graph` (tree-sitter queries, go-to-definition,

go-to-references, full and incremental indexing).

The single largest gap between the coder and the agents it benchmarks

against is orientation speed on an unfamiliar repository. Terminal-Bench

fix-the-bug and implement-the-feature tasks begin with minutes of `ls`,

`grep`, and dead-end file reads. A `repo_map` plugin takes a workspace

mount and returns a bounded structural map: directories that matter, public

symbols per file, definition sites for a named symbol, reference counts.

Tree-sitter compiles to WASM cleanly, which is why this crate is the

highest-confidence port in the list. Start with the two or three grammars

the Gym suites actually hit (Python, TypeScript, Rust) rather than Grok's

full language set.

**Needs from the host:** a workspace mount. Today's manifests declare fixed

home-relative paths (`~/.claude`); this plugin needs the manifest to declare

a mount the host resolves to the session's working directory. That

parameterized mount is the one host change this whole document asks for, and

targets 2, 4, 5, and 6 reuse it.

### 2. `repo_tree` — gitignore-aware listing

**Source:** `xai-grok-tools/src/gitignore.rs`, `xai-file-utils`,

`xai-fuzzy-file-search`.

The first thing every benchmark run does is look around, and the coder does

it today with raw `ls` and `find` — unfiltered, unbounded, and re-sent to

the model every round it stays in context. A `repo_tree` plugin returns a

gitignore-filtered tree with per-entry size and kind, bounded by depth and

entry ceilings, plus a fuzzy name lookup (`"authcontroller"` finds

`auth_controller.ex`) so the model stops spending rounds guessing paths.

Pure listing over the workspace mount; small; probably the best

delta-per-effort in the list.

### 3. `session_search` — search what any agent already learned

**Source:** `xai-grok-session-search` (the other half of the lineage

`foreign_sessions` came from), `xai-sqlite-journal` for Grok's own store.

`read_conversation` reads one session; this searches all of them.

Terminal-Bench aside, this is the memory primitive the fleet keeps

reinventing: "have I — or any agent on this machine — hit this error

before?" Input is a query string and the same source/cwd filters the

scanner takes; output is matching sessions with bounded surrounding

context per hit. Same two mounts the existing pair already declares, so it

ships with no host changes at all. Plain substring and identifier matching

first; ranking can come later without a schema change.

### 4. `git_facts` — structured status, log, and blame

**Source:** `xai-gix-status` (gitoxide status), `xai-hunk-tracker`

(hunk-level change tracking), `xai-fast-worktree` for the read side.

The coder answers "what changed?" by shelling `git` and re-reading prose.

Benchmark tasks that hand the agent a dirty repository — and the coder's own

verify-before-claim discipline — want typed answers: current branch, staged

and unstaged paths with hunk counts, the last N commits touching a path,

who last changed a line. Gitoxide is pure Rust and compiles to WASM;

`.git` is just files under the workspace mount. Read-only by construction —

commits and pushes stay in core, where the push guards live.

### 5. `test_report` — parse the test run the shell just did

**Source:** none — this one is ours, but it earns its place here because

Grok's `tool_taxonomy` treats "run" and "understand the run" as one native

step, and a sandboxed coder cannot. The shell tool runs `pytest`, `cargo

test`, `mix test`, or `jest`; this pure plugin parses the captured output

into typed failures: file, test name, assertion, the relevant traceback

lines. Terminal-Bench grades on making tests pass, and today the model

re-reads the same 300-line dump every round it iterates. A pure text-in,

JSON-out plugin, no mounts at all — the cheapest kind the ABI supports —

and likely the largest single Gym delta on the fix-the-tests task class.

### 6. `patch_check` — validate a diff before claiming it

**Source:** `xai-hunk-tracker`, and Grok's edit-tool normalization

(`xai-grok-tools/src/normalization.rs`).

A pure plugin that takes a unified diff plus the target file's current

content and answers: does this hunk apply, where does it drift, what would

the file look like after. The coder's edit loop occasionally emits patches

that no longer apply after an earlier edit; today that surfaces as a shell

round-trip and a confused retry. Validation as a capability keeps the write

itself in core while making the check free.

### 7. `token_count` — budget arithmetic for context planning

**Source:** `xai-token-estimation`.

Pure computation: text or file-listing in, token estimates per item out.

Long Gym runs die of context exhaustion mid-task; a model that can ask

"which of these five files fits my remaining budget" plans instead of

truncating. Pairs with `xai-compaction-transcript`'s idea — a

`compact_notes` plugin that reduces a long tool transcript to a bounded

structured summary — but token counting alone is an afternoon of work and

immediately measurable.

## Explicitly not harvested

Named so the next reader does not re-derive the refusals:

- **Subagents, background tasks, worktree checkpoints, rewind**

  (`xai-workflow`, `xai-fast-worktree`'s write side, section 9 of the

  teardown): lifecycle features, not one-shot capabilities. The coder's

  delegation and thread lanes own this ground.

- **Web search and fetch:** need host allowlists, which the approval

  posture currently auto-approves nothing for. A capability with network

  reach is a different trust conversation, deliberately deferred.

- **LSP integration** (`ToolKind::Lsp`): a long-lived server per language,

  wrong shape for the sandbox. `repo_map` covers the read-only half of what

  the benchmarks need from it.

- **Media generation, deploy, voice** (`ImageGen`, `DeployApp`,

  `xai-grok-voice`): not coding-agent work; no Gym suite grades them.

- **Grok's plugin marketplace** (`xai-grok-plugin-marketplace`): the

  registry lane already exists here (forge-hosted, issue #206 closed);

  what to harvest is their manifest fields, not their store.

## Sequencing

`repo_tree` and `test_report` first — no host changes, small crates, both

sit directly under the Terminal-Bench task classes the Gym already grades.

The parameterized workspace mount lands with `repo_tree`'s successor

`repo_map`, and `git_facts` follows it on the same mount. `session_search`

can land any time; it needs nothing new. Every landing follows the Gym

rule: same recipe, score before, score after, delta attributed to the

digest.