Integration: MCP provider for Claude Code subscription (no API keys)

[abhinaykrupa]

Feature Area

Core functionality

Is your feature request related to a an existing bug? Please link it here.

N/A

Describe the solution you'd like

Problem

Crew.ai users who want to use Claude Code on their machine face a challenge: Crew.ai agents can't directly access Claude Max/Pro subscription for local execution.

Current options:

• API key (separate billing, loses local context)
• • Claude Code CLI (no integration path)
• • • Custom tools (manual wiring, complex setup)

Solution: Use cowork-to-code-bridge as MCP Provider

cowork-to-code-bridge is an open-source daemon that exposes Claude Code via MCP (Model Context Protocol). Crew.ai agents can now escalate work to Claude Code on the same machine.

Reference Implementation

GitHub: https://github.com/abhinaykrupa/cowork-to-code-bridge
MCP Docs: https://github.com/abhinaykrupa/cowork-to-code-bridge/blob/main/docs/MCP_SERVER_IMPLEMENTATION.md
Integration Guide: https://github.com/abhinaykrupa/cowork-to-code-bridge/blob/main/docs/EXTERNAL_AGENT_INTEGRATION.md

Describe alternatives you've considered

No response

Additional context

No response

Willingness to Contribute

Yes, I'd be happy to submit a pull request

[Keesan12]

This seems worth doing, but I would model it less like "another provider" and more like "a local delegated runtime" with its own failure semantics.

A few things I would lock down early:

• capability discovery needs to be explicit, because a Claude Code bridge can usually do tools / file context / local execution that a normal API provider cannot
• request boundaries should be stateful by design; if Crew spins up long-lived agents, you probably want a clear policy for when a Claude Code session is reused vs restarted
• typed failures matter a lot here (claude_not_installed, subscription_unavailable, workspace_not_trusted, tool_call_denied) so the orchestration layer can degrade cleanly instead of treating every miss like a model error
• streaming and cancellation should be first-class, otherwise local runs that stop being useful can keep burning time with no operator signal

The big product win is not only avoiding extra API billing. It is letting the agent escalate into the developer's real local context without pretending that path behaves like a stateless remote LLM.

If you wire this, I'd be especially curious how you expose the capability contract back into Crew so plans can choose the bridge intentionally instead of accidentally.

[github-actions]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[IgorGanapolsky]

Reliability note

Production automation failures usually reduce to a contract issue before a model/prompt issue:

1. Success criteria — durable artifact id (message/booking/row), not only node green
2. Side-effect before complete — never blind-retry without an idempotency key on the business object
3. Tool vs path split — external action can succeed while the node/agent path still errors (silent-green / false-red)

If you have one failing execution + expected vs actual, reply with stack/version and I will send a free root-cause checklist.