[Feature request] ACP Support

Codebuff SDK is very promising, Codebuff as an Coding Agent looks insanely customizable and I like very much your systematic approach to building things. Great work!

One thing Codebuff lacks is some UI and instead of writing yet-another-web-ui for it I would like you to consider implementing Agent Client Protocol (by Zed). Which being pretty recent addition to the Vibe Condig world is pretty well established:

See:

I use both Claude Code (not not exclusively with Antrophic's models) and Gemini CLI (due it's generous free tier) daily inside Zed. Vim and other non-VSCode editor's users can benefit from ACP support too spreading Codebuff's userbase. And I bet someone eventually will vibe-code yet-another-web-ui for ACP inself unsing Codebuff integration;)

Marking this stale - there has been no activity here for 328 days. It will close in 7 days unless someone comments.

This is backlog upkeep, not a verdict on the issue. A single comment keeps it open, and anything closed this way can be reopened.

+1 for acp ;)

+1

Marking this stale - there has been no activity here for 29 days. It will close in 7 days unless someone comments.

This is backlog upkeep, not a verdict on the issue. A single comment keeps it open, and anything closed this way can be reopened.

please speed i need this 🙏

another +1 for ACP

+1

@jahooma

ACP support is now up as #1611: it serves ACP v1 over stdio (via the official @agentclientprotocol/sdk), so Zed and other ACP clients can drive the CLI as a subprocess:

freebuff --acp # suggested command

# For early testing from the PR branch:
git clone git@github.com:espetro/freebuff.git
cd freebuff
git checkout feature/acp-agent
bun install
bun freebuff/cli/build.ts 0.0.0-dev
./cli/bin/freebuff --acp

# Test without building a binary:
bun run cli/src/entry.ts --acp

Two findings from prototyping this that shaped the design:

It has to live in the official binary. An external SDK wrapper driving free mode with the user's device token gets refused by the backend ("third-party client, harness or proxy", with a ban warning after repeats). So the adapter runs inside the CLI process and reuses the same run path the TUI takes; therefore, session admission, freebuff_instance_id metadata and device signing are unchanged.
The SDK is the right transport after all. Feature request: headless/print mode + SDK support for freebuff authToken (for third-party orchestrators) #947's Option B premise (the SDK refuses the freebuff token) is not quite the blocker: the token authenticates fine at the backend the released binary actually uses (https://www.codebuff.com); what fails is the client allowlist, which an in-tree flag satisfies.

Scope kept deliberately small (~20 lines outside cli/src/acp/): no ACP auth flow (the CLI's own login is auth), no session persistence across process restarts, no permission round-trips yet (follow-up: map overrideTools to session/request_permission).

heads up @jahooma @charleslien @brandonkachen ; flagging since #319 has been open a while; happy to rework the mapping or trim scope. A separate npm package is not viable for free mode because of (1), worth knowing if anyone else proposes one.

Navigation Menu

Repository navigation

[Feature request] ACP Support #319

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Feature request] ACP Support #319

Description

Activity

codebuff-team commented on Aug 22, 2026

zoop-dev commented on Aug 30, 2026

yukazakiri commented on Sep 22, 2026

codebuff-team commented on Oct 21, 2026

notkainoa commented on Oct 27, 2026

Atom1cByte commented on Oct 30, 2026

yukazakiri commented on Oct 30, 2026

espetro commented on Nov 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions