Files
fusion/plugins/fusion-plugin-grok-runtime
gsxdsm cae7847085 fix(FN-8004): retry ACP provider blips in auto-merge instead of parking failed (#2157)
## What happened

FN-8004's implementation work finished and passed review. The auto-merge
then failed with `Grok ACP turn failed: Internal error` — a ~20 second
provider blip — and the task was parked `status: "failed"` with 8 files
of complete, reviewed work stranded on its branch.

The park is the interesting part: `status: "failed"` is precisely what
tells recovery to stop. So a misclassification here isn't a missed
retry, it's **terminal**. Both recovery paths were disabled by the same
wrong verdict:

- `maybeRetryTransientMerge` (inline, 3 retries w/ backoff) — never
fired once (`mergeTransientRetryCount: 0`).
- `recoverTransientMergeFailures` (self-healing sweep, exists exactly to
rescue parked in-review tasks) — skipped it, gated on the same
classifier.

## Three defects fixed

**1. No AI-provider failure class existed.** The AI merge drives a real
LLM turn, but `classifyTransientMergeError` only modeled git/lease/spawn
faults. Adds `ai-provider-turn-failure`.

**2. ACP dropped the error detail.** `promptAcpSession` rethrew the SDK
error unchanged, discarding the JSON-RPC `code`/`data` — the only
evidence the fault was provider-side. ("Internal error" is just the
standard text for `-32603`.) It now preserves them, keeping the original
as `cause`:

```
Internal error (acp rpc code -32603, retryable)
```

Classification anchors on that envelope, **not** on the bare `"Internal
error"` — matching that unanchored would disguise genuine application
defects as retryable blips. Only provider-fault codes (`-32603`,
`-32000`..`-32003`) are retryable; caller-fault codes
(`-32600`..`-32602`) stay permanent, since retrying just repeats the
failing call.

**3. Sweep/inline asymmetry** (found while tracing; latent and
unreported). The inline gate accepted `isTransientError(msg) ||
classify(msg)`, but the sweep consulted **only** the classifier. So
`ECONNRESET` / `socket hang up` during a merge earned inline retries and
then went **invisible to the sweep** once parked — stranded forever. The
classifier now delegates to `isTransientError`, so both gates agree by
construction.

To keep that delegation from importing the detector's
`usage-limit-detector → logger` chain (the chain FN-5627 split the
classifier out to avoid, which would break
`notification-service.test.ts`'s partial `vi.mock`), the pure predicates
moved to the import-free leaf `transient-error-patterns.ts`, re-exported
from `transient-error-detector.ts`. All 13 exports preserved, verified
programmatically.

## Loosened budgets

Per request, so more self-heals. Both apply **only** to errors already
proven transient; the ceiling and
`merger:transient-failure-budget-exhausted` audit path remain.

| Budget | Before | After |
|---|---|---|
| `MAX_AUTO_MERGE_TRANSIENT_RETRIES` | 3 | 5 (backoff
5s/10s/20s/40s/80s) |
| `MAX_TRANSIENT_MERGE_RECOVERIES` | 2 | 5 |

The bump broke two suites that had hardcoded the old `3`. Rather than
swap in another magic number, both now derive the cap from the constant
so future tuning doesn't re-break them.

## Verification

- `pnpm test:gate` green · `pnpm lint` clean · engine + ACP typecheck
clean · `pnpm verify:fast` PASS (5/5)
- ACP plugin 230 tests green · Grok plugin 64 green · engine
transient/merge suites 136 green
- Regression tests assert the **invariant across every surface** (per
*Fix the Invariant, Not the Repro*), not just the reported Grok string:
both ACP runtime prefixes, all retryable/non-retryable rpc codes, both
SDK error shapes, network delegation, class-ordering, and negative cases
proving bare `"Internal error"` and real defects stay permanent.
- A test caught a genuine bug in my own code mid-review (nested-shape
message shadowing), now fixed.
- `notifier.test.ts > "awaiting approval"` fails — **confirmed
pre-existing on clean main**, unrelated.

## Note

FN-8004's own branch (`fusion/fn-8004`) is still unmerged and its work
looks complete. Once this lands, its merge should be retried separately.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-15 20:14:25 -07:00
..
2026-07-13 10:32:12 -07:00
2026-07-13 10:32:12 -07:00

fusion-plugin-grok-runtime

Grok CLI-backed provider/runtime plugin for Fusion. Agent sessions use native ACP (grok agent stdio) for realtime streaming, tool visibility, and multi-turn reuse.

Install

This plugin ships bundled with Fusion and is auto-installed like the other built-in runtime plugins. It shells out to an operator-installed grok binary on PATH — Fusion never downloads or bundles the CLI itself.

  • Canonical upstream: xAI official Grok CLI / Grok Build TUI (grok --version observed as grok 0.2.93 (f00f96316d4b)).
  • Docs / homepage: https://grok.com/, https://docs.x.ai/, https://docs.x.ai/build/overview, and grok --help / grok agent stdio --help.
  • ACP protocol: https://agentclientprotocol.com
  • Release / download: operator-installed; Fusion resolves grok from PATH or grokCliBinaryPath.
  • Binary name: grok.
  • Checksum: upstream-pending-verification because Fusion does not download or pin the operator's binary.

The previously assumed superagent-ai/grok-cli contract is a different product that shares the grok binary name. This plugin targets xAI's official CLI contract.

Contract summary

  • Provider ID: grok-cli
  • Binary probe: grok --version
  • Auth model — the grok CLI owns its own authentication; Fusion does not require a Fusion-visible API key to enable/use it (FN-7716). Fusion additionally probes the GROK_API_KEY env var and ~/.grok/user-settings.json → { "apiKey": "..." } purely as a non-blocking informational hint (apiKeyDetected); it never gates Enable or the authenticated state. The direct xAI OpenAI-compatible streaming path (base URL https://api.x.ai/v1) still uses $GROK_API_KEY when present, independent of the CLI provider.
  • Model discovery: grok models (plain text). The observed xAI shape is Default model: <id>, then Available models:, then * <id> (default) / - <id> bullet rows.

Agent session path — ACP (primary)

GrokRuntimeAdapter drives xAI's native ACP server with a vendored ACP client (copied under src/acp/, not imported from fusion-plugin-acp-runtime):

grok agent stdio
# optional model:
grok agent -m grok-4.5 stdio
  • Realtime streaming — ACP session/update notifications map to Fusion onText / onThinking / onToolStart / onToolEnd as chunks arrive (not buffered until process exit).
  • Multi-turn — one createSession keeps the ACP connection; each promptWithFallback is a session/prompt on the same session.
  • Permissions — Grok tool calls surface as session/request_permission and go through Fusion's per-category action gate.
  • Fusion tools (fn_*) — engine customTools are exposed to Grok as MCP server fusion-custom-tools (executable bridge, not schema-only).
  • Operator MCP — configured Fusion MCP servers (stdio/http/sse) are forwarded on ACP session/new.mcpServers.
  • Skills — the bundled Fusion skill plus session additionalSkillPaths / requested skill names are staged into a trusted --plugin-dir plugin so Grok discovers them like a native plugin.
  • Env — subprocess env is allow-listed (includes HOME/PATH/XDG so ~/.grok/auth.json works, plus optional XAI_API_KEY/GROK_API_KEY). Full process.env is never inherited.
  • Auth implication: because the grok binary resolves its own credentials for this path, a CLI-routed selection needs no Fusion-visible GROK_API_KEY when a cached grok.com session exists — unlike the direct xAI OpenAI-compatible streaming path.

See docs/grok-cli-contract.md for the full contract, failure history (FN-7790/FN-7796 headless paths), and diagnostics invariants.

Routing Grok through the CLI runtime (FN-7725 / FN-7753 / FN-7790)

By default, selecting a grok-cli/* model for an agent/task routes through the direct xAI OpenAI-compatible endpoint (https://api.x.ai/v1, FN-7711/FN-7714) whenever Fusion can see a GROK_API_KEY (environment or ~/.grok/user-settings.json apiKey). If no Fusion-visible key resolves and the Grok Runtime plugin is registered, Fusion automatically routes that session through the grok CLI runtime instead, letting the CLI own auth end-to-end.

To route a specific agent's execution through the grok CLI runtime explicitly:

  1. Open the agent in the dashboard (New Agent or an existing agent's detail view).
  2. Under Runtime Source, choose Runtime instead of Built-in Model.
  3. Select Grok Runtime from the runtime dropdown (sourced from GET /api/plugins/runtimes).
  4. Save. The agent's runtimeConfig.runtimeHint is now "grok"; every session that agent drives resolves through this plugin's GrokRuntimeAdapter instead of the default pi runtime.

Automatic fallback precedence (FN-7753): explicit runtime hint > Fusion-visible key/direct endpoint > automatic CLI fallback. The fallback is only derived when no explicit runtime hint is set, the provider is grok-cli, no Fusion-visible key resolves, and runtime id "grok" is registered. The selected model is normalized from grok-cli/<id> (or grok/<id>) to <id> and sent as grok agent -m <id> stdio.

Known limitation: explicit Runtime-mode is still model-agnostic — it does not carry a specific grok-cli/* model id through to the adapter, so GrokRuntimeAdapter.createSession() falls back to "grok/default" and omits -m. Built-in Model selections preserve the model either through the direct endpoint (when a key is visible) or through the FN-7753 automatic CLI fallback (when no key is visible).

Enable via Settings → Authentication

  1. Install the grok CLI and authenticate it (grok login or XAI_API_KEY) — Fusion does not need to see the key for the CLI path.
  2. Open Settings → Authentication in the Fusion dashboard.
  3. The "Grok — via Grok CLI" card shows probe status. Click Enable once the binary is available; a non-blocking hint appears only if Fusion did not detect a key, noting the direct xAI streaming path uses GROK_API_KEY when present.
  4. Discovered Grok models (via grok models) then merge into the model picker under the grok-cli provider id.

Notes

Do not invent a grok status/whoami JSON auth contract — readiness is derived from binary availability, mirroring the Cursor CLI provider. See AGENTS.md's "External-integration evidence" policy for why the release/checksum fields above stay at upstream-pending-verification.