You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: Evaluate upstreaming native A2A support from a working prototype #18021
The problem today is that A2A support has to live in downstream integrations. That makes interoperability with external agents harder and keeps this capability outside the main project.
My proposal is to evaluate whether OpenCode should expose first-class A2A support incrementally, using the existing prototype as a reference instead of designing from scratch.
This is related to #17374, but the difference here is that I already have a working implementation and can help translate it into an upstream-friendly design.
If this direction is interesting to the team, I am happy to help with design discussion, implementation breakdown, and follow-up PRs.
Reacted by Olivier D'Ancona, Robin, Dennis Rutjes and Pavel Plotnikov
No issue template was used. This issue should be submitted as a Feature Request (title must start with [FEATURE]:, include a verification checkbox, and describe the enhancement) or a Question (with a clear question in the required field).
Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
changed the title [-][Proposal] I have built A2A protocol support for OpenCode and can help upstream it[/-][+][FEATURE]: Consider upstream A2A protocol support from an existing implementation[/+]on Mar 18, 2026
Thank you for updating the issue! It now follows the contributing guidelines and the feature request template correctly. The compliance flag has been removed.
changed the title [-][FEATURE]: Consider upstream A2A protocol support from an existing implementation[/-][+][FEATURE]: Evaluate upstreaming native A2A support from a working prototype[/+]on Mar 18, 2026
@liujuanjuan1984, great work on the prototype! One aspect I believe we should discuss during the design phase is the authentication layer between OpenCode and the external agents.
Currently, the prototype assumes that the caller is already handling credentials. However, for the native integration, it would be beneficial to integrate the M2M (Machine-to-Machine) Client Credentials flow as the standard approach. The idea is that OpenCode would request a short-lived JWT that is scoped to what the specific agent requires, attach it to the A2A request, and the external agent would then validate this token. This way, no personal tokens would be stored in local configurations.
By using M2M, we also ensure least privilege by design: if the LLM encounters a bad prompt injection, the agent token can only perform actions that were allowed at the time of registration.
The @a2a-js/sdk already supports injecting authentication headers through the client factory, making it a seamless addition to your existing work.
I'm happy to help brainstorm the design for credential storage if this direction aligns with your vision.
Activity
github-actions commentedon Mar 18, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
[FEATURE]:, include a verification checkbox, and describe the enhancement) or a Question (with a clear question in the required field).Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
If you believe this was flagged incorrectly, please let a maintainer know.
[-][Proposal] I have built A2A protocol support for OpenCode and can help upstream it[/-][+][FEATURE]: Consider upstream A2A protocol support from an existing implementation[/+]github-actions commentedon Mar 18, 2026
Thank you for updating the issue! It now follows the contributing guidelines and the feature request template correctly. The compliance flag has been removed.
[-][FEATURE]: Consider upstream A2A protocol support from an existing implementation[/-][+][FEATURE]: Evaluate upstreaming native A2A support from a working prototype[/+]laiweihwa commentedon Mar 29, 2026
I just noticed today that this exists, @liujuanjuan1984
https://github.com/shashikanth-gs/a2a-opencode
I have not audited or tried it yet.
liujuanjuan1984 commentedon Mar 30, 2026
Thank you for your info. And I'm working on it for a while: https://github.com/Intelligent-Internet/opencode-a2a
odanilosalve commentedon Jun 4, 2026
@liujuanjuan1984, great work on the prototype! One aspect I believe we should discuss during the design phase is the authentication layer between OpenCode and the external agents.
Currently, the prototype assumes that the caller is already handling credentials. However, for the native integration, it would be beneficial to integrate the M2M (Machine-to-Machine) Client Credentials flow as the standard approach. The idea is that OpenCode would request a short-lived JWT that is scoped to what the specific agent requires, attach it to the A2A request, and the external agent would then validate this token. This way, no personal tokens would be stored in local configurations.
By using M2M, we also ensure least privilege by design: if the LLM encounters a bad prompt injection, the agent token can only perform actions that were allowed at the time of registration.
The @a2a-js/sdk already supports injecting authentication headers through the client factory, making it a seamless addition to your existing work.
I'm happy to help brainstorm the design for credential storage if this direction aligns with your vision.
hamza-abdalmajeed commentedon Jul 9, 2026
Hi @kitlangton is this something thats planned to be pulled into OpenCode?
github-actions commentedon Sep 8, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.