This is pretty egregious. And outside the fact the server is now disabled by default, once it's running it is still egregious:
> When server is enabled, any web page served from localhost/127.0.0.1 can execute code
> When server is enabled, any local process can execute code without authentication
> No indication when server is running (users may be unaware of exposure)
I'm sorry this is horrible. I really want there to be a good actual open cross-provider agentic coding tool, but this seems to me to be abusive of people's trust of TUI apps - part of the reason we trust them is they typically DON'T do stuff like this.
Many people seem to be running OpenCode and similar tools on their laptop with basically no privilege separation, sandboxing, fine-grained permissions settings in the tool itself. This tendency is reflected also by how many plugins are designed, where the default assumption is the tool is running unrestricted on the computer next to some kind of IDE as many authentication callbacks go to some port on localhost and the fallback is to parse out the right parameter from the callback URL. Also for some reasons these tools tend to be relative resource hogs even when waiting for a reply from a remote provider. I mean, I am glad they exist, but it seems very rough around the edges compared to how much attention these tools get nowadays.
Please run at least a dev-container or a VM for the tools. You can use RDP/ VNC/ Spice or even just the terminal with tmux to work within the confines of the container/ machine. You can mirror some stuff into the container/ machine with SSHFS, Samba/ NFS, 9p. You can use all the traditional tools, filesystems and such for reliable snapshots. Push the results separately or don't give direct unrestricted git access to the agent.
It's not that hard. If you are super lazy, you can also pay for a VPS $5/month or something like that and run the workload there.
I really like the product created by fly.io's https://sprites.dev/ for AI's sandboxes effectively. I feel like its really apt here (not sponsored lmao wish I was)
Oh btw if someone wants to run servers via qemu, I highly recommend quickemu. It provides default ssh access,sshfs, vnc,spice and all such ports to just your local device of course and also allows one to install debian or any distro (out of many many distros) using quickget.
I personally really like zed with ssh open remote. I can always open up terminals in it and use claude code or opencode or any and they provide AI as well (I dont use much AI this way, I make simple scripts for myself so I just copy paste for free from the websites) but I can recommend zed for what its worth as well.
My original message was more positive but after more looking into context, I am a bit more pessimistic.
Now I must admit though that I am little concerned by the fact that the vulnerability reporters tried multiple times to contact you but till no avail. This is not a good look at all and I hope you can fix it asap as you mention
I respect dax from the days of SST framework but this is genuinely such a bad look especially when they Reported on 2025-11-17, and multiple "no responses" after repeated attempts to contact the maintainers...
Sure they reported the bug now but who knows what could have / might have even been happening as OpenCode was the most famous open source coding agent and surely more cybersec must have watched it, I can see a genuine possibility where something must have been used in the wild as well from my understanding from black hat adversaries
I think this means that we should probably run models in gvisor/proper sandboxing efforts.
Even right now, we don't know how many more such bugs might persist and can lead to even RCE.
Dax, This short attention would make every adversary look for even more bugs / RCE vulnerabilities right now as we speak so you only have a very finite time in my opinion. I hope things can be done as fast as possible now to make OpenCode more safer.
the email they found was from a different repo and not monitored. this is ultimately our fault for not having a proper SECURITY.md on our main repository
the issue that was reported was fixed as soon as we heard about it - going through the process of learning about the CVE process, etc now and setting everything up correctly. we get 100s of issues reported to us daily across various mediums and we're figuring out how to manage this
i can't really say much beyond this is my own inexperience showing
I am also baffled at how long this vulnerability was left open, but I’m glad you’re at least making changes to hopefully avoid such mistakes in the future.
Just a thought, have you tried any way to triage these reported issues via LLMs, or constantly running an LLM to check the codebase for gaping security holes? Would that be in any way useful?
Anyway, thanks for your work on opencode and good luck.
Good luck, and thank you for eating the accountability sandwich and being up front about what you're doing. That's not always easy to do, and it's appreciated!
I've been curious how this project will grow over time, it seems to have taken the lead as the first open source terminal agent framework/runner, and definitely seems to be growing faster than any organization would/could/should be able to manage.
It really seems like the main focus of the project should be in how to organize the work of the project, rather than on the specs/requirements/development of the codebase itself.
What are the general recommendations the team has been getting for how to manage the development velocity? And have you looked into various anarchist organizational principles?
WTF, they not just made unauthenticated RCE http endpoint, they also helpfully added CORS bypass for it... all in CLI tool? That silently starts http server??
They keep adding features without maintaining the core. I stopped using it when they started selling plans. The main reason for Opencode was to use multiple models but it turns out context sharing across models is PIA and impractical right now. I went back to using Claude Code and Codex side by side.
Having said that, there is definitely a need for open platform to utilize multiple vendors and models. I just don’t think the big three (Anthropic, OAI and Google) will cede that control over with so much money on the line.
As someone who uses the two big C's, I can recommend ampcode[0] and Crush[1]+z.ai GLM as an addition.
Amp can do small utility scripts and changes for free (especially if you enable the ads) and Crush+GLM is pretty good at following plans done by Claude or Codex
If you aren't blocking your browser from allowing sites to call to local services, you should:
> Network Boundary Shield
> The Network Boundary Shield (NBS) is a protection against attacks from an external network (the Internet) to an internal network - especially against a reconnaissance attack where a web browser is abused as a proxy.
> The main goal of NBS is to prevent attacks where a public website requests a resource from the internal network (e.g. the logo of the manufacturer of the local router); NBS will detect that a web page hosted on the public Internet is trying to connect to a local IP address. NBS only blocks HTTP requests from a web page hosted on a public IP address to a private network resource; the user can allow specific web pages to access local resources (e.g. when using Intranet services).
Seems `session/:id/shell` was also `session/:id/bash` and originally `session/:id/command` in some commits.
Maybe I'm using GitHub code search wrongly, but it appears this was just never part of even a pull request - the practice of just having someone pushing to `dev` (default branch) which then will be tagged should perhaps also be revisited.
(Several more commits under `wip: bash` and `feat: bash commands`)
Huh, I thought opencode was a volunteer project but it looks like it's a business with major backing from major players. Was opencode always set up like this? I could have sworn there was some project with a better governance model, guess not.
This is such an egregious lack of respect for users, you can't trust this organisation again, and the lack of responsiveness just signals that they don't consider it a problem. Users must signal to companies that this attitude is unacceptable by dumping them.
So did they fix it silently, without responding to the researcher, or they fixed the silent part where now user is made a aware that a website is trying to execute code on their machine.
It's under "Vendor Advisory", so I'm guessing it's that they fixed it, but never informed any OpenCode users that there was a massive security vulnerability.
I was investigating that for entirely unrelated reasons just yesterday and the answer so far seems to be "none". You can patch the server to serve the locally built frontend and it all works just fine.
On the one hand, with 1800 open issues and 800 open PRs (most of it probably AI generated slop) makes it a bit understandable for the maintainers to be slow to reply. On the other hand, the vulnerability is so baffling that I'll make sure to stay as far away as possible from this project.
This is pretty egregious. And outside the fact the server is now disabled by default, once it's running it is still egregious:
> When server is enabled, any web page served from localhost/127.0.0.1 can execute code
> When server is enabled, any local process can execute code without authentication
> No indication when server is running (users may be unaware of exposure)
I'm sorry this is horrible. I really want there to be a good actual open cross-provider agentic coding tool, but this seems to me to be abusive of people's trust of TUI apps - part of the reason we trust them is they typically DON'T do stuff like this.
Factory’s droid is pretty good for a cross-provider solution.
Many people seem to be running OpenCode and similar tools on their laptop with basically no privilege separation, sandboxing, fine-grained permissions settings in the tool itself. This tendency is reflected also by how many plugins are designed, where the default assumption is the tool is running unrestricted on the computer next to some kind of IDE as many authentication callbacks go to some port on localhost and the fallback is to parse out the right parameter from the callback URL. Also for some reasons these tools tend to be relative resource hogs even when waiting for a reply from a remote provider. I mean, I am glad they exist, but it seems very rough around the edges compared to how much attention these tools get nowadays.
Please run at least a dev-container or a VM for the tools. You can use RDP/ VNC/ Spice or even just the terminal with tmux to work within the confines of the container/ machine. You can mirror some stuff into the container/ machine with SSHFS, Samba/ NFS, 9p. You can use all the traditional tools, filesystems and such for reliable snapshots. Push the results separately or don't give direct unrestricted git access to the agent.
It's not that hard. If you are super lazy, you can also pay for a VPS $5/month or something like that and run the workload there.
I really like the product created by fly.io's https://sprites.dev/ for AI's sandboxes effectively. I feel like its really apt here (not sponsored lmao wish I was)
Oh btw if someone wants to run servers via qemu, I highly recommend quickemu. It provides default ssh access,sshfs, vnc,spice and all such ports to just your local device of course and also allows one to install debian or any distro (out of many many distros) using quickget.
Its really intuitive for what its worth, definitely worth a try https://github.com/quickemu-project/quickemu
I personally really like zed with ssh open remote. I can always open up terminals in it and use claude code or opencode or any and they provide AI as well (I dont use much AI this way, I make simple scripts for myself so I just copy paste for free from the websites) but I can recommend zed for what its worth as well.
hey maintainer here
we've done a poor job handling these security reports, usage has grown rapidly and we're overwhelmed with issues
we're meeting with some people this week to advise us on how to handle this better, get a bug bounty program funded and have some audits done
My original message was more positive but after more looking into context, I am a bit more pessimistic.
Now I must admit though that I am little concerned by the fact that the vulnerability reporters tried multiple times to contact you but till no avail. This is not a good look at all and I hope you can fix it asap as you mention
I respect dax from the days of SST framework but this is genuinely such a bad look especially when they Reported on 2025-11-17, and multiple "no responses" after repeated attempts to contact the maintainers...
Sure they reported the bug now but who knows what could have / might have even been happening as OpenCode was the most famous open source coding agent and surely more cybersec must have watched it, I can see a genuine possibility where something must have been used in the wild as well from my understanding from black hat adversaries
I think this means that we should probably run models in gvisor/proper sandboxing efforts.
Even right now, we don't know how many more such bugs might persist and can lead to even RCE.
Dax, This short attention would make every adversary look for even more bugs / RCE vulnerabilities right now as we speak so you only have a very finite time in my opinion. I hope things can be done as fast as possible now to make OpenCode more safer.
the email they found was from a different repo and not monitored. this is ultimately our fault for not having a proper SECURITY.md on our main repository
the issue that was reported was fixed as soon as we heard about it - going through the process of learning about the CVE process, etc now and setting everything up correctly. we get 100s of issues reported to us daily across various mediums and we're figuring out how to manage this
i can't really say much beyond this is my own inexperience showing
I am also baffled at how long this vulnerability was left open, but I’m glad you’re at least making changes to hopefully avoid such mistakes in the future.
Just a thought, have you tried any way to triage these reported issues via LLMs, or constantly running an LLM to check the codebase for gaping security holes? Would that be in any way useful?
Anyway, thanks for your work on opencode and good luck.
Good luck, and thank you for eating the accountability sandwich and being up front about what you're doing. That's not always easy to do, and it's appreciated!
I've been curious how this project will grow over time, it seems to have taken the lead as the first open source terminal agent framework/runner, and definitely seems to be growing faster than any organization would/could/should be able to manage.
It really seems like the main focus of the project should be in how to organize the work of the project, rather than on the specs/requirements/development of the codebase itself.
What are the general recommendations the team has been getting for how to manage the development velocity? And have you looked into various anarchist organizational principles?
Why not just ask Claude to fix the security issues and make sure they don't happen again?
Talk about kicking someone while they're down...
And if you don't have a Claude subscription, you can just ask your friends to fix them via the remote code execution server.
Who knows what created the issues in the first place place
Congrats on owning this, good job, respect
It's hard to not own it when it's publicly disclosed. Maybe save the accolades for when they actually do something and not just say something.
Hmm, dax seems more of an adult is his response than you sound in this comment.
Plenty of examples of people who implode when things get public, here it is being managed decently, even if not from the get-go.
In my limited existence on this earth, talk is very cheap and actions should matter more.
Good idea. Start sending in some PRs to contribute then.
Respect for openness. Good work and good luck.
Its okay, if you can fix it soon, it should be fine.
WTF, they not just made unauthenticated RCE http endpoint, they also helpfully added CORS bypass for it... all in CLI tool? That silently starts http server??
I'm slightly surprised that the CORS policy wasn't just "*" considering how wide open the server itself was.
That's the point, it was!
https://github.com/anomalyco/opencode/commit/7d2d87fa2c44e32...
It seems like it was prior to 1.0.216?
The disclosure timeline is concerning.
Reported 2025-11-17, and multiple "no responses" after repeated attempts to contact the maintainers... not a good look.
it looks like opencode developers now try to take it seriously:
https://github.com/anomalyco/opencode/issues/6355#issuecomme...
They keep adding features without maintaining the core. I stopped using it when they started selling plans. The main reason for Opencode was to use multiple models but it turns out context sharing across models is PIA and impractical right now. I went back to using Claude Code and Codex side by side.
Having said that, there is definitely a need for open platform to utilize multiple vendors and models. I just don’t think the big three (Anthropic, OAI and Google) will cede that control over with so much money on the line.
As someone who uses the two big C's, I can recommend ampcode[0] and Crush[1]+z.ai GLM as an addition.
Amp can do small utility scripts and changes for free (especially if you enable the ads) and Crush+GLM is pretty good at following plans done by Claude or Codex
[0] https://ampcode.com/
[1] https://github.com/charmbracelet/crush
It feels that today security is secondary to growth. As long as your growing, a few incidents here and there aren't going to make a difference.
If you aren't blocking your browser from allowing sites to call to local services, you should:
> Network Boundary Shield
> The Network Boundary Shield (NBS) is a protection against attacks from an external network (the Internet) to an internal network - especially against a reconnaissance attack where a web browser is abused as a proxy.
> The main goal of NBS is to prevent attacks where a public website requests a resource from the internal network (e.g. the logo of the manufacturer of the local router); NBS will detect that a web page hosted on the public Internet is trying to connect to a local IP address. NBS only blocks HTTP requests from a web page hosted on a public IP address to a private network resource; the user can allow specific web pages to access local resources (e.g. when using Intranet services).
https://jshelter.org/nbs/
Seems `session/:id/shell` was also `session/:id/bash` and originally `session/:id/command` in some commits.
Maybe I'm using GitHub code search wrongly, but it appears this was just never part of even a pull request - the practice of just having someone pushing to `dev` (default branch) which then will be tagged should perhaps also be revisited.
(Several more commits under `wip: bash` and `feat: bash commands`)
https://github.com/anomalyco/opencode/commit/7505fa61b9caa17...
https://github.com/anomalyco/opencode/commit/93b71477e665600...
Huh, I thought opencode was a volunteer project but it looks like it's a business with major backing from major players. Was opencode always set up like this? I could have sworn there was some project with a better governance model, guess not.
You are either thinking of crush, roocode or kilo, they all started around the same time and dont have backing from major players yet.
https://github.com/opencode-ai/opencode there was also the competing opencode which because crush done by charm.sh people.
Isn't it insane that any web page can run a port scan in the first place? Who wants that?
Meanwhile, running opencode in a podman container seems to stop this particular, err, feature.
If you use uBlock Origin you can enable the "Privacy -> Block Outsider Intrusion into LAN" filter list to mitigate this.
This is such an egregious lack of respect for users, you can't trust this organisation again, and the lack of responsiveness just signals that they don't consider it a problem. Users must signal to companies that this attitude is unacceptable by dumping them.
> Silent fix
So did they fix it silently, without responding to the researcher, or they fixed the silent part where now user is made a aware that a website is trying to execute code on their machine.
It's under "Vendor Advisory", so I'm guessing it's that they fixed it, but never informed any OpenCode users that there was a massive security vulnerability.
I'd be curious to know what features need opencode.ai to be an allowed origin for the local server.
I was investigating that for entirely unrelated reasons just yesterday and the answer so far seems to be "none". You can patch the server to serve the locally built frontend and it all works just fine.
app.opencode.ai frontend
On the one hand, with 1800 open issues and 800 open PRs (most of it probably AI generated slop) makes it a bit understandable for the maintainers to be slow to reply. On the other hand, the vulnerability is so baffling that I'll make sure to stay as far away as possible from this project.
How's that plastic utensils at Anthropic's buffet analogy going now?