ACP provider support in Goose: current state and next steps

[lifeizhou-ap]

We would like to share our direction for supporting external coding agents through ACP providers in Goose.

Background

Goose currently supports external agents through the AcpProvider wrapper:

Goose agent loop
  → AcpProvider
    → external ACP agent
      → external agent loop

Agents such as Claude Code and Codex already manage their own context, tools, permissions, and session lifecycle. Running them through Goose’s normal provider interface requires translating between two independent agent loops.

This introduces considerable complexity around streaming, tool events, cancellation, retries, permissions, steering, and session restoration.

How ACP providers are used today

Our current understanding is:

• The Claude Code ACP provider is primarily used to access Claude Code through an existing Claude subscription. A Claude subscription does not provide access through Anthropic’s normal model API, so there is no equivalent standard Goose provider that uses the subscription today.
• The Codex ACP provider can also use an existing ChatGPT subscription. However, Codex users can migrate to Goose’s standard chatgpt-codex provider without relying on the ACP provider path.

This means the Claude Code ACP provider may require a longer transition, while Codex already has an alternative within Goose.

Alternatives we considered

We considered moving ACP agents outside the Goose agent loop and introducing an ACP pass-through or proxy execution path.

An ACP-to-ACP proxy could be relatively straightforward for clients that already communicate through ACP. It could allow Goose to record conversations, support inspection, and potentially switch between agents.

Supporting the same experience in Goose CLI would be substantially more involved because CLI input is not ACP-shaped. It would require additional conversion, lifecycle, and session infrastructure rather than a simple proxy.

Given the implementation effort and currently uncertain demand, we have decided not to prioritize this architectural work.

What we plan to do

• Deprecate all ACP providers except the Claude Code ACP provider and Codex ACP provider.
• Keep the Claude Code ACP provider and Codex ACP provider available for existing users, without pursuing architectural fixes or changes that add substantial complexity.
• Recommend chatgpt-codex as the standard alternative for Codex users.
• Recommend that users with an ACP-capable client connect directly to claude-agent-acp, the Claude Code ACP server, instead of routing through Goose’s Claude Code ACP provider.
• Avoid adding new ACP providers or significant new functionality to the existing ACP provider path.
• Eventually remove the Claude Code ACP provider and Codex ACP provider. We will announce the timing and provide migration guidance before any removal.

This change applies only to ACP agents configured as Goose model providers. Goose’s support for exposing Goose itself over ACP is unaffected.

We may evaluate other Claude Code integration options in the future, but none are currently prioritized or scheduled. A direct integration would still require substantial lifecycle and session-management work.

We'd like to understand current usage

If you currently use an ACP provider in Goose, please let us know:

• Which ACP provider do you use?
• Do you use it through Goose Desktop, CLI, or both?
• Why do you use an ACP provider in Goose?

If our understanding above doesn’t cover your use case, we'd especially like to hear from you. Your feedback will help us understand how ACP providers are used today and inform our next steps.

[kojiromike]

Which ACP provider do you use?

Claude Code, to wit https://github.com/agentclientprotocol/claude-agent-acp

Do you use it through Goose Desktop, CLI, or both?

Desktop, mainly

Why do you use an ACP provider in Goose?

Basically money. I've had the best experience doing agentic coding with Claude over other AI, but the best experience using Goose to interact with coding agents – better than Claude Code directly, even with the current clunkiness of ACP. I can use Goose with Claude through regular API calls, but that seems to require paying per token. Paying per token is way more expensive than Claude Code. This is the best compromise I've found so far.

[kojiromike]

I should add more color to why I prefer Goose to Claude Code.

It's important to me that as much of my dev tooling as possible be open source, within practicality. I can't practically run 100% open weights models today, but I can interface with them using open source software, which Claude Code is not.

Also the user experience using Goose is better. Claude is fastidious with permissions, but its permissions rules aren't expressive enough. Claude Code stops me constantly to check, and when I give it enough rein, it goes too far. I feel that Goose reliably runs Claude Code further without stopping to check, but hasn't crossed any lines, either.

[alexhancock]

This is really good feedback, thanks @kojiromike. Glad it's currently layering on some value for you

[manpombo-rgb]

Which ACP provider do you use?

Claude Code,

Do you use it through Goose Desktop, CLI, or both?

A bit of both. Mostly CLI

Why do you use an ACP provider in Goose?

I have a claude subscription but I mostly use goose with my local model. However, if I need a sota model or need the speed I can easily escalate the workflow to Claude. The removal of structured support for recipes via ACP was bad for my workflow, removing support for Claude code altogether via CLI would force me to look for another client.

I understand the need for this discussion as there are so many things in flight but the integration with my Claude subscription was kind of a killer feature for me.

[lifeizhou-ap]

Thanks for sharing these use cases. @kojiromike @manpombo-rgb!

We’re considering keeping the Claude Code ACP provider available in its current form while marking it as deprecated. We would limit maintenance to small fixes and wouldn’t undertake major architectural changes or add substantial new functionality. We wouldn’t remove it without advance notice and migration guidance.

Would that work for you?

[johanndrews]

So it would mean, that in the future, claude code could only be used with an usage based pricing and api key? Or what is the alternative for that?

[lifeizhou-ap]

Although the original post mentioned eventually removing the Claude Code ACP provider, the feedback here has made us reconsider.

We have no current plan or timeline to remove the Claude Code ACP provider. We would only consider replacing it if we had an alternative implementation that preserved access through Claude subscriptions.

We'll keep the Claude Code ACP provider available in its current form and consider small bug and compatibility fixes that don't require major architectural changes or add significant complexity.

[johanndrews]

We are using claude code acp within the CLI.
I started using goose, BECAUSE it had the ACP for claude code and it is possible to use the subscription. :)
Like opencode or others, you can only use the API (and it would cost too much ...)

[alexhancock]

@johanndrews Thanks for the feedback!

I wonder why you use goose CLI to access Claude Code instead of just using Claude Code. We know people want to do this with goose, but understanding why is really key for our team so we can make it a better experience for you while keeping it maintainable for us.

[johanndrews]

My easy point is this: I started using only claude code, then we know some ugly part of "claude fable is banned" moment in Europe and I felt, it was time to go a a safer and more flexible route, where I can, if needed, change just the model within my process I build for our usecases. So I transferred the process to goose and now orchestrate Claude Opus from there. And in fact I already reduced the dependency of claude by mixing also other models into the process, but for now claude opus is still generating the best solutions for me in regard of being the planner in my process and I used for different scenarios, f.e. for reviews and where I need other opinions not from the same model that generated the base that needs to be judged.

[AnthonyRonning]

This is very unfortunate to hear about the deprecation of ACP. I use it heavily and there is a whole world out there beyond just codex and claude acp connectors. I myself use 5 different harnesses in ACP via Paseo, and I was looking forward to building out the Maple Agent on top of Goose to have ACP support into other harnesses in a similar way.

The way I see it is that each harness is different, with different skill sets, connectors, subscription plans, integrations, knowledge bases, etc.

Removing ACP means that more needs to be owned by Goose in order to meet the level of excellence that other harnesses and integrations have perfected for their use cases, and I think that's unattainable by a single agent harness alone. Which is why I consider agents being able to call other agents via ACP a must have.

[lifeizhou-ap]

Thanks for sharing your use case! ❤️

I would like make sure we're distinguishing it from the existing AcpProvider implementation.

Although AcpProvider communicates with a downstream ACP agent, it is not a proxy through which a Goose agent delegates work to another agent. Instead, it places the external agent behind Goose’s normal model-provider interface, resulting in nested agent loops and lifecycle complexity.

Your use case sounds like it may involve an orchestration layer built on top of Goose’s ACP agent interface. That seems like a separate feature from the current AcpProvider implementation. We are interested in what gets shared between those agents in Maple.

[AnthonyRonning]

Maybe I was confused about a potential future thing. I am interested in Goose's ability to call agents or subagents (that exist in other providers like opencode/codex/etc.) in an ACP way. Not sure if that ever landed or if that was still planned, I remember seeing some diagrams with that.

[alexhancock]

@AnthonyRonning Let's definitely discuss and work together on what would be helpful for you in this area.

What we have right now for goose controlling codex and claude code is kind of disorganized and has a higher maintenance burden then we'd like, so @lifeizhou-ap has been leading the charge on a simplification effort.

I think there are perhaps better things we could do in future, but would like to base it on user requirements/demand. Any specific patterns you'd want to enable?

[AnthonyRonning]

@alexhancock - One of the bigger features that me and our users want is for our agent to be able to control other agents. ACP seemed to be the most supported way to have that done and one of the use cases I saw in some of Goose's presentations that I got really excited about. Alternatively I can just build this out on our side if it is removed in Goose.

[sirmacik]

ACP support for me was the reason why I was finally able to implement goose in my workflows, which I wasn't able to do before. So, looking at the changes proposed, I do feel it will make me look for other the solution.

I use codex, Claude and custom ACP compatible programs in both CLI and GUI. Goose serves me as a very efficient orchestration layer for orchestrating multiple tools for ad hoc and scheduled jobs.