feat(lody): support Kimi, Grok, ACP Registry, and Custom ACP agents

[pythonlearner1025]

Component

new provider / integration

Problem

BlitzOS currently exposes only Claude Code and Codex in Lody sessions, even though Lody upstream supports additional built-in agents, ACP Registry runtimes, and custom ACP launch commands.

The limitation is in the BlitzOS integration rather than the Lody protocol:

• packages/webapp/src/lody/agent-configs.ts seeds only blitz-claude and blitz-codex machine Flock rows.
• packages/box/Dockerfile installs and pins only Claude Code and Codex, with Blitz credential shims and explicit runtime overrides.
• All upstream settings routes, including /settings/agents and /settings/agent-config, are empty stubs in the Blitz Lody router, so members cannot create registry or Custom ACP configs.
• agent-auth-notice.tsx is hard-coded to Claude even though Lody's underlying authentication panel supports other built-in agents.
• Upstream Agent Config environment values are persisted in machine Flock rows. BlitzOS must not put API keys into this synced CRDT; credentials need to stay behind blitz-cred and be injected only into the launched process.

The current Lody integration is also behind upstream:

• vendored renderer pin: f34748945028ffc04316861ad25edc24535c0235
• daemon pin: lody@0.88.1
• upstream observed during investigation: 896fd1e04c24876fce7f0f4aa1dee1eae773a73b, 86 commits ahead
• current npm release observed: lody@0.89.4

Those upstream changes include standard ACP authentication for registry agents and completed interactive authentication for Custom ACP, so agent expansion should not be built on the old pair.

The upstream merge runbook has drifted and must be corrected before using it. docs/LODY-MERGE.md still says to expect exactly eight divergent files and to re-audit "both" npm-artifact patches. vendor/lody/BLITZ-PATCHES.md now declares eight seam patches affecting at least fourteen hunk-bearing vendor files, and the box image applies three npm-artifact patches.

Proposed solution

Implement this in four bounded phases.

Phase 0: repair the merge contract and update Lody

• Update docs/LODY-MERGE.md so its divergent-file allowlist matches all current seam patches.
• Update references from two to three npm-artifact patches.
• Create a dedicated worktree/branch and pull Lody using the documented squashed-subtree procedure.
• Preserve the git-subtree-split marker; do not rebase, amend, or squash the subtree merge commit.
• Update the renderer subtree and daemon as a verified pair, targeting lody@0.89.4 if the pulled tree and release are confirmed compatible.
• Re-anchor every declared vendor seam and remove any seam already fixed upstream instead of reapplying it.
• Re-audit hashes, versions, anchors, and application order for all three patches in packages/box/patches/.
• Refresh the committed upstream baselines used by the Lody seam tests.
• Run npm run typecheck, npm run lint:gate, and npm test.

Phase 1: add first-class Kimi Code and Grok support

Lody's built-in catalog contains Claude Code, Codex, Kimi Code, Grok, and DeepSeek Harness. Add Kimi and Grok first because both have upstream managed runtimes and interactive sign-in flows; they do not require storing an API key in an Agent Config row.

• Add stable blitz-kimi and blitz-grok config IDs and machine Flock rows.
• Widen the Blitz Agent Config row type for kimiPath and grokPath runtime overrides.
• Decide and document the runtime policy:
  • canary option: use Lody's versioned, checksum-verified managed downloads;
  • production/offline option: bake the exact runtimes into the box image and point overrides at pinned executable paths.
• Generalize the in-session authentication notice so it derives the selected config/agent from session metadata instead of always rendering Claude.
• Keep the generic upstream AcpAuthenticationPanel flow for Kimi and Grok sign-in.
• Extend bootstrap, capability-refresh, authentication, composer-selection, and full session round-trip tests for both agents.
• Verify cancellation, permission modes, model discovery, worktree sessions, and session recovery with each agent against a real daemon.

Phase 2: expose an allowlisted Agent settings surface

• Mount upstream MachineAgentSettings at /$workspaceName/settings/agents.
• Make /$workspaceName/settings/agent-config redirect to the Agents page as upstream does.
• Remove only those paths from SETTINGS_STUB_PATHS; leave unrelated unsupported settings routes stubbed.
• Add a BlitzOS settings/navigation entry that reaches the page.
• Update the source and DOM scope tests that currently require all upstream settings pages to be empty.
• Initially allowlist registry agents whose runtime and authentication story is explicitly supported in the box image. Use OpenCode as the first non-built-in target.
• Install required local commands at pinned versions, or explicitly approve a checksum-pinned managed-download path.
• Do not silently enable arbitrary npx, uvx, binary downloads, or custom commands; treat each as execution of third-party code and expose the policy clearly.
• Test capability probing, configuration save/edit/delete, launch, authentication, and error recovery for the allowlisted registry agent.

The upstream ACP registry currently includes 39 entries such as OpenCode, Gemini CLI, GitHub Copilot, Cursor, Devin, Cline, Goose, Amp, Factory Droid, Qwen Code, Kimi CLI, Junie, Mistral Vibe, GLM Agent, DeepSeek Reasonix, Auggie, Kilo, and pi ACP. Registry presence alone does not mean the runtime is installed or approved for BlitzOS.

Phase 3: secure API-key and Custom ACP support

• Define a non-secret Agent Config representation that stores a credential name/reference, never its value.
• Resolve credentials through blitz-cred only at process launch and scope them to the child ACP process.
• Ensure credential values never enter Flock rows, session metadata, files, logs, command previews, or the daemon's long-lived environment.
• Add a launcher/wrapper boundary that can inject credentials for built-in, registry, and Custom ACP agents without patching every agent independently.
• Restrict upstream's free-form environment editor to non-secret values, or replace it with a Blitz credential selector plus an explicit non-secret environment section.
• Add DeepSeek Harness using DEEPSEEK_API_KEY supplied by the credential launcher.
• Add one API-key-backed Claude-compatible preset as the conformance case; then extend the same mechanism to GLM, MiniMax, MiMo, Qwen, and DeepSeek-over-Claude.
• Define authorization/audit behavior for arbitrary Custom ACP commands before enabling them.
• Add negative tests proving secrets are absent from CRDT state, RPC payloads that do not require them, logs, errors, and rendered config summaries.

Acceptance criteria

• Existing Claude Code and Codex sessions remain unchanged, including their pinned shims and credential behavior.
• A member can select, authenticate, and complete a real session with Kimi Code and Grok.
• A member can configure and complete a real session with at least one allowlisted ACP Registry agent, initially OpenCode.
• Capability discovery correctly populates each supported agent's models, modes, effort controls, and permission options.
• Agent configuration survives reload and daemon restart without duplicate rows or lost runtime overrides.
• No credential value is persisted in Lody/Blitz CRDT documents or exposed to the browser.
• Unsupported registry/custom runtimes fail before launch with a clear, actionable explanation.
• Lody subtree and npm-daemon pins are recorded as a verified pair and all vendor/npm patches are revalidated.
• Full repository typecheck, lint gate, and test suite pass.

Alternatives considered

1. Seed every upstream agent immediately. Rejected because registry entries have different installation, platform, authentication, and supply-chain requirements, and API-key configs would violate the current credential boundary.
2. Mount upstream Agent settings unchanged. Rejected because its environment editor persists values in Agent Config rows; that is not safe for BlitzOS workspace credentials.
3. Use only Lody-managed downloads. Suitable for a canary, but production may require baked runtimes for offline startup, reproducibility, and tighter supply-chain control.
4. Implement each provider as a separate bespoke integration. Rejected after the initial Kimi/Grok phase; ACP Registry plus one credential-aware launcher gives a smaller and more maintainable long-term boundary.

Relevant files

• docs/LODY-MERGE.md
• vendor/lody/UPSTREAM.md
• vendor/lody/BLITZ-PATCHES.md
• vendor/lody/packages/shared/src/ai.ts
• vendor/lody/packages/shared/src/acp/registry-generated.ts
• packages/webapp/src/lody/agent-configs.ts
• packages/webapp/src/lody/agent-auth-notice.tsx
• packages/webapp/src/lody/router.tsx
• packages/box/Dockerfile
• packages/box/patches/