fix(cli): support custom ACP history synchronization

[UniversePeak]

Related issue

Closes #187

Problem / pressure

The local-project history UI lists every agent configuration, including custom ACP agents, but the history sync launch path only received cliType and agentType. Builtin and registry agents can resolve their executables from static definitions; a custom agent's executable is stored in its machine-scoped customAcp configuration. As a result, every custom history sync failed before spawning the ACP process with Custom ACP <agentType> has no launch command configured.

Summary

• Allow the local-project control guard to accept custom ACP history providers.
• Resolve the daemon-authoritative custom agent configuration for the requested machine and provider before history work starts.
• Thread the resolved customAcp launch spec through the shared history catalog client so session listing and replay use the same command and arguments as normal custom ACP sessions.
• Apply the resolved launch to sync, selected-session import, and conflict-resolution replay paths without widening the control-plane provider wire contract.
• Add regression coverage for custom launch resolution and custom history control requests.

Visual explanation

flowchart LR
    UI["Local-project history UI"] -->|"syncHistory / importHistory / resolveHistoryConflict"| Guard["Local-project control guard"]
    Guard -->|"custom ACP provider accepted"| Client["history-session-catalog-client"]
    Client -->|"list / import / replay request"| Daemon["Owning daemon"]
    Daemon -->|"resolve machine-scoped customAcp config for cliType:agentType"| Spec["Launch spec: command + argv (+ env)"]
    Spec -->|"spawn history ACP process"| ACP["Custom ACP server"]
    Daemon -->|"missing config or command: unchanged clear failure"| Err["Error: no launch command configured"]

Loading

Custom ACP providers now pass the same control boundary as builtin and registry providers, and the daemon supplies the launch command from its authoritative machine-scoped configuration on every history entry point.

Before / after

Before	After
Custom ACP providers appeared in local-project history settings but were rejected by the remote control guard or reached launch resolution without a command.	Custom providers pass the control boundary, and the owning daemon resolves their current machine-scoped customAcp command before spawning history ACP processes.
History listing/import/conflict resolution could never start a custom ACP process.	All history entry points share the resolved custom launch while builtin and registry behavior remains unchanged.

Test plan

• corepack pnpm --filter acp-extension-core build — passed, required local ACP package entry was built.
• corepack pnpm --filter acp-extension-claude build — passed, required local workspace entry was built.
• corepack pnpm --filter lody typecheck — passed.
• corepack pnpm --filter @lody/shared typecheck — passed.
• corepack pnpm --filter lody exec vitest run tests/history-session-catalog-client.test.ts -t 'custom ACP' — passed, 1 test.
• corepack pnpm --filter @lody/shared exec vitest run tests/local-project-control.test.ts — passed, 29 tests.
• corepack pnpm --filter lody exec vitest run tests/local-project-history-sync-service.test.ts — passed, 30 tests.
• Focused type-aware oxlint on changed CLI/shared files — 0 errors.
• Prettier checks on all changed files and git diff --check — passed.
• Full @lody/shared suite — 1,012 passed, 3 unrelated baseline failures (one local CLI host-lease assertion and two source-guard tests timed out); no changed history-control test failed.

Context handoff

Instructions for reviewing agents

• Review focus: Check LocalProjectHistorySyncService.resolveLaunchProvider, the three history operation paths, and history-session-catalog-client.ts to ensure only daemon-authoritative machine config supplies the custom command.
• Decisions to challenge: Confirm that resolving by machine plus cliType:agentType is the right identity boundary and that keeping customAcp out of the control-plane wire schema avoids trusting caller-supplied executable paths.
• Plausible failures / evidence gaps: The full shared suite retains three unrelated baseline failures; live spawning of a user-provided ACP server was not run, while the launch resolver regression verifies exact command and argv propagation.

Authoring context

• User goal / directives: Make local-project history synchronization work for custom ACP agents using the command already stored in their agent configuration.
• Constraints / non-goals: Keep builtin and registry launches unchanged, do not accept executable paths from the RPC caller, do not duplicate the custom command in session metadata, and do not broaden the change beyond local-project history operations.
• Risk-bearing decisions: The daemon reads the merged config for the target machine and provider, then passes that trusted launch spec through list/replay; a missing config or command retains the existing clear failure instead of falling back.
• Destructive or irreversible behavior: None; this changes process-launch selection and adds tests only, with no persistence migration or user-data rewrite.
• Deliberately not done or tested: No live custom ACP server was launched and no full desktop build was run; focused type, lint, history-service, control-schema, and launch-resolution checks cover the changed paths.
• Unknowns / confidence: High confidence in the control and launch plumbing; the remaining uncertainty is compatibility with varied third-party custom ACP servers, which CI and maintainer review can exercise.

Original user prompt

Show original prompt

Local-project history synchronization does not work for custom ACP agents. The history UI lists custom ACP agents, but every custom history sync fails before launch with "Custom ACP <agentType> has no launch command configured", because the launch path only receives cliType and agentType while a custom agent's executable lives in its machine-scoped customAcp configuration. Make the history sync resolve and use the command already stored in the agent's customAcp configuration, without changing builtin and registry behavior.

Shared conversation

Status: unavailable
Reason: The authoring conversation was conducted in a local Hermes assistant environment that does not provide a public conversation-sharing link.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 87f89b469c

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Update the CommonJS control guard for custom providers

When @lody/shared/node/local-project-control is loaded via require—the package's declared CommonJS export—the request is validated by local-project-control.cjs, whose provider guard still accepts only builtin and registry. Consequently, every custom sync, import, or conflict-resolution request is rejected before reaching the new resolver for CommonJS consumers; mirror this change in the CJS implementation and exercise that export in the test.

AGENTS.md reference: AGENTS.md:L123-L129

Useful? React with 👍 / 👎.