feat(agent,cli): add cursor-acp provider via ACP

[RobertoVillegas]

Summary

Adds Cursor ACP as a native Hermes model provider using Cursor's Agent Client Protocol (agent acp). This follows the existing external-process provider pattern used by copilot-acp, but targets Cursor's CLI instead of GitHub Copilot.

This lets users use Cursor Composer, including cursor/composer-2.5, directly as a Hermes backend after agent login, without a separate Cursor API key.

Why

Cursor Composer is not exposed through a normal chat-completions API. The supported local integration surface is the Cursor CLI ACP server:

• Cursor ACP docs: https://cursor.com/docs/cli/acp
• Cursor auth docs: https://cursor.com/docs/cli/reference/authentication

This complements #30641, which adds Cursor as a delegated tool through the Cursor SDK. This PR is for the other use case: selecting Cursor as the active Hermes provider in the model picker.

Changes

• Add agent/cursor_acp_client.py, an OpenAI-compatible shim around agent acp.
• Register cursor-acp in provider metadata, aliases, auth status, and runtime resolution.
• Add Cursor model catalog entries:
  • cursor/composer-2.5
  • cursor/composer-2
  • cursor/default
  • cursor-acp
• Wire cursor-acp into agent client creation and auxiliary client resolution.
• Treat cursor-acp as an external-process provider in /model discovery.
• Disable normal streaming for cursor-acp because ACP handles its own subprocess stream.
• Add regression tests for model catalog, aliases, runtime resolution, and model picker visibility.

How to test

Prerequisites:

curl https://cursor.com/install -fsS | bash
agent login

Then:

hermes chat --provider cursor-acp --model cursor/composer-2.5 -q "Say hello from Cursor ACP"

Or use /model and select Cursor ACP.

Validation

Local validation on macOS:

python -m py_compile \
  agent/cursor_acp_client.py \
  agent/agent_runtime_helpers.py \
  agent/auxiliary_client.py \
  hermes_cli/auth.py \
  hermes_cli/providers.py \
  hermes_cli/runtime_provider.py \
  hermes_cli/models.py \
  hermes_cli/model_switch.py

python -m pytest \
  tests/hermes_cli/test_cursor_acp_provider.py \
  tests/hermes_cli/test_runtime_provider_resolution.py \
  tests/hermes_cli/test_copilot_in_model_list.py \
  -q

Result:

134 passed

Manual smoke test performed on macOS 26.4.1 with Cursor CLI agent v2026.05.20-2b5dd59 and Cursor Individual subscription. cursor/composer-2.5 responded successfully through Hermes.

Platform tested

• macOS 26.4.1
• Python 3.11
• Cursor CLI ACP via agent acp

Related

• feat(tools): add cursor_agent tool via Cursor SDK #30641: Cursor SDK tool integration, complementary to this provider
• RFC: Cursor SDK (Composer 2.5) as cursor_agent tool + optional bridge #30640: Cursor SDK RFC

[alt-glitch]

Related to #2758 (earlier Cursor ACP provider PR) and #16282 (feature request for ACP harness beyond Copilot). Also overlaps with #18471 (Cursor harness route) and #5258 (generalized ACP client).

[RobertoVillegas]

Coordination note: the paired WebUI PR nesquena/hermes-webui#2792 has been rebased and updated to depend on this Agent-side cursor-acp provider support. WebUI now gates the reasoning-effort chip by provider/model so Cursor Composer routes through cursor-acp without showing unsupported effort controls.

[teknium1]

Thanks for the work here — closing this with the rest of the Cursor-related PRs and the underlying RFC (#30640).

After looking at all four integration surfaces (CLI ACP, Python/TS SDK, Cloud Agents REST, and the unofficial standardagents proxy), they all wrap Cursor's agent harness — tools, permissions, modes, subagents, planning UX — and there is no raw inference endpoint for Composer 2.5. Cursor sells Composer as an agent, not a model.

That's a clean answer for what your PR does, but it isn't the integration shape we want for Hermes. Selecting it as a "provider" would silently disable Hermes' own tools, memory, skills, and MCP setup for that turn, and delegating to it as a tool just reproduces what codex / claude-code / opencode already cover. We'd rather wait for a real chat-completions endpoint (Cursor has hinted at one) than ship an agent-as-provider integration that confuses what's actually executing.

Closing for now — appreciate the effort and the careful design. If Cursor ships a direct model endpoint we'd happily revisit.