Skip to content

Proposal: use ACP as the common integration boundary for agent CLIs #152

Description

@surenny

Motivation

Loopany can launch multiple agent CLIs, but observability currently depends on each CLI stream format. Claude stream-json, native Codex JSONL, and other agent outputs differ in how they represent messages, thoughts, tool calls, file changes, sessions, errors, and token usage. Adding a bespoke parser for every CLI makes trace quality inconsistent and increases maintenance cost.

ACP already defines a common session and event protocol for coding agents. Using it as Loopany’s preferred integration boundary would let the daemon consume one normalized event model while prompts, credentials, and execution remain local.

Proposed direction

  • Prefer ACP for agent CLIs with a usable local adapter.
  • Normalize ACP events into the existing Loopany run model: live activity, transcript, tool results, changed files, session identity, usage, and errors.
  • Keep native CLI execution as a compatibility and rollback path during migration.
  • Keep agent-specific translation inside the ACP adapter rather than adding another parser directly to Loopany for every CLI.

Codex proof of concept

I have implemented the Codex path in #151. It uses pinned local acpx + codex-acp, one named session per run, strict JSON-RPC parsing, retry/resume support, normalized traces and artifacts, and detailed token/context metrics. Native codex exec --json remains the default unless ACP is explicitly enabled.

If the maintainers agree with this direction, we would be happy to follow up with a cleaner agent-neutral transport boundary and help adapt additional agent CLIs to ACP. The intent is not to require a large registry; the number of supported agents is small, and a simple explicit adapter boundary should be sufficient.

Related implementation: #151

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions