hey maintainer here<p>we've done a poor job handling these security reports, usage has grown rapidly and we're overwhelmed with issues<p>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
Don't waste your time and money on funding bug bounties or "getting audits done". Your staff will add another big security flaw just the next day, back to square one.<p>Spend that money in reorganizing your management and training your staff so that everyone in your company is onboard with <a href="https://owasp.org/Top10/2025/A06_2025-Insecure_Design/" rel="nofollow">https://owasp.org/Top10/2025/A06_2025-Insecure_Design/</a> .
My original message was more positive but after more looking into context, I am a bit more pessimistic.<p>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<p>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...<p>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<p>I think this means that we should probably run models in gvisor/proper sandboxing efforts.<p>Even right now, we don't know how many more such bugs might persist and can lead to even RCE.<p>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<p>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<p>i can't really say much beyond this is my own inexperience showing
Also consider putting a security.txt[0] file on your main domain, like here: <a href="https://opencode.ai/.well-known/security.txt" rel="nofollow">https://opencode.ai/.well-known/security.txt</a><p>I also just want to sympathize with the difficulty of spotting the real reports from the noise. For a time I helped manage a bug bounty program, and 95% of issues were long reports with plausible titles that ended up saying something like "if an attacker can access the user's device, they can access the user's device". Finding the genuine ones requires a lot of time and constant effort. Though you get a feel for it with experience.<p>[0] <a href="https://en.wikipedia.org/wiki/Security.txt" rel="nofollow">https://en.wikipedia.org/wiki/Security.txt</a><p>edit: I agree with the original report that the CORS fix, while a huge improvement, is not sufficient since it doesn't protect from things like malicious code running locally or on the network.<p>edit2: Looks like you've already rolled out a password! Kudos.
I've been thinking about using LLMs to help triage security vulnerabilities.<p>If done in an auditably unlogged environment (with a limited output to the company, just saying escalate) it might also encourage people to share vulns they are worried about putting online.<p>Does that make sense from your experience?<p>[1] <a href="https://github.com/eb4890/echoresponse/blob/main/design.md" rel="nofollow">https://github.com/eb4890/echoresponse/blob/main/design.md</a>
Thanks for providing additional context. I appreciate the fact that you are admitting fault where it is and that's okay because its human to make errors and I have full faith from your response that OpenCode will learn from its errors.<p>I might try OpenCode now once its get patched or after seeing the community for a while. Wishing the best of luck for a more secure future of opencode!
I learnt this the hard way: if anyone is sending multiple emails, with seemingly very important titles and messages, and they get no reply at all, the receiver likely haven’t received your email rather than completely ghosting you.
Everyone should know this, and at least try a different channel of communication before further actions, especially from those disclosing vulnerability.
Fixed? You just change it to be off by default giving the security burden to your users. It's not fixed it's buried with minimal mitigation and you give no indication to your users that it will make your machine vulnerable if activated. Shady.
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.<p>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?<p>Anyway, thanks for your work on opencode and good luck.
They are a small team and tool has gotten wildly popular. Which is not to say that slowing down and addressing quality and security issues would not be a bad idea.<p>I’ve been an active user of opencode for 7-8 months now, really like the tool, but beginning to get a feeling that the core team’s idea of keeping the core development to themselves is not going to scale any longer.<p>Really loving opencode though!
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
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.<p>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.<p>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?
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!
Congrats on owning this, good job, respect
I don't know much about your product, but I have to say that hearing this kind of blunt communication is really refreshing
Respect for openness. Good work and good luck.
I don't understand what is being encouraged here.<p>Something is seriously wrong when we say "hey, respect!" to a company who develops an unauthenticated RCE feature that should <i>glaringly shine</i> [0] during any internal security analysis, on software that they are licensing in exchange for money [1], and then fumble and drop the ball on security reports when someone does their due diligence for them.<p>If this company wants to earn any respect, they need at least to publish their post-mortem about how their software development practices allowed such a serious issue to reach shipping.<p>This should come as a given, especially seeing that this company already works on software related to security (OpenAuth [2]).<p>[0] <a href="https://owasp.org/Top10/2025/" rel="nofollow">https://owasp.org/Top10/2025/</a>
- <a href="https://owasp.org/Top10/2025/A06_2025-Insecure_Design/" rel="nofollow">https://owasp.org/Top10/2025/A06_2025-Insecure_Design/</a>
- <a href="https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/" rel="nofollow">https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/</a>
- <a href="https://owasp.org/Top10/2025/A05_2025-Injection/" rel="nofollow">https://owasp.org/Top10/2025/A05_2025-Injection/</a><p>[1] <a href="https://opencode.ai/enterprise" rel="nofollow">https://opencode.ai/enterprise</a><p>[2] <a href="https://anoma.ly/" rel="nofollow">https://anoma.ly/</a>
I’ve noticed this a lot with startup culture.<p>It’s like an unwritten rule to only praise each other because to give honest criticism invites people to do the same to you and too much criticism will halt the gravy train.
Honestly RCE here is in the browser. Why the browser executes any code in sight and this code can do anything?
It's called "the world wide web" and it works on the principle that a webpage served by computer A can contain links that point to other pages served by computer B.<p>Whether that principle should have been sustained in the special case of "B = localhost" is a valid question. I think the consensus from the past 40 years has been "yes", probably based on the amount of unknown failure possibilities if the default was reversed to "no".
owasp A01 addresses this: Violation of the principle of least privilege, commonly known as deny by default, where access should only be granted for particular capabilities, roles, or users, but is available to anyone.<p>Indeed, deny by default policy results in unknown failure possibilities, it's inherent to safety.
>Violation of the principle of least privilege<p>I completely agree with this, programs are too open most of the time.<p>But, this also brings up a conundrum...<p>Programs that are wide open and insecure typically are very forgiving of user misconfigurations and misunderstandings, so they are the ones that end up widely adopted. Whereas a secure by default application takes much more knowledge to use in most cases, even though they protect the end user better, see less distribution unless forced by some other mechanism such as compliance.
Its okay, if you can fix it soon, it should be fine.
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.<p>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.<p>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.
Hi.<p>> Please run at least a dev-container or a VM for the tools.<p>I would like to know how to do this. Could you share your favorite how-to?
I have a pretty non-standard setup but with very standard tools. I didn't follow any specific guide. I have ZFS as the filesystem, for each VM a ZVOL or dataset + raw image and libvirt/ KVM on top. This can be done using e.g. Debian GNU/ Linux in a somewhat straight forward way. You can probably do something like it in WSL2 on Windows although that doesn't really sandbox stuff much or with Docker/ Podman or with VirtualBox.<p>If you want a dedicated virtual host, Proxmox seems to be pretty easy to install even for relative newcomers and it has a GUI that's decent for new people and seasoned admins as well.<p>For the remote connection I just use SSH and tmux, so I can comfortably detach and reattach without killing the tool that's running inside the terminal on the remote machine.<p>I hope this helps even though I didn't provide a step-by step guide.
If you are using VSCode against WSL2 or Linux and you have installed Docker, managing devcontainers is very straightforward. What I usually do is to execute "Connect to host" or "Connect to WSL", then create the project directory and ask VSCode to "Add Dev Container Configuration File". Once the configuration file is created, VSCode itself will ask you if you want to start working inside the container. I'm impressed with the user experience of this feature, to be honest.<p>Working with devcontainers from CLI wasn't very difficult [0], but I must confess that I only tested it once.<p>[0] <a href="https://containers.dev/supporting" rel="nofollow">https://containers.dev/supporting</a>
>> Please run at least a dev-container or a VM for the tools.<p>> I would like to know how to do this. Could you share your favorite how-to?<p>See: <a href="https://www.docker.com/get-started/" rel="nofollow">https://www.docker.com/get-started/</a><p>EDIT:<p>Perhaps you are more interested in various sandboxing options. If so, the following may be of interest:<p><a href="https://news.ycombinator.com/item?id=46595393">https://news.ycombinator.com/item?id=46595393</a>
Note that while containers can be leveraged to run processes at lower privilege levels, they are not secure by default, and actually run at elevated privileges compared to normal processes.<p>Make sure the agent cannot launch containers and that you are switching users and dropping privileges.<p>On a Mac you are running a VM machine that helps, but on Linux it is the user that is responsible for constraints, and by default it is trivial to bypass.<p>Containers have been fairly successful for security because the most popular images have been leveraging traditional co-hosting methods, like nginx dropping root etc…<p>By themselves without actively doing the same they are not a security feature.<p>While there are some reactive defaults, Docker places the responsibility for dropping privileges on the user and image. Just launching a container is security through obscurity.<p>It can be a powerful tool to improve security posture, but don’t expect it by default.
Hi. You are clearly an LLM user. Have you considered asking an LLM to explain how to do this? If not, why not?
Claude asks you for permissions every time it wants to run something.
That's why you run with "dangerously allow all." What's the point of LLMs if I have to manually approve everything? IME you only get half decent results if the agent can run tests, run builds and iterate. I'm not going to look at the wall of texts it produces on every iterations, they are mostly convincing bullshit. I'll review the code it wrote once the tests pass, but I don't want to be "in the loop".
Until you run --dangerously-skip-permissions
I really like the product created by fly.io's <a href="https://sprites.dev/" rel="nofollow">https://sprites.dev/</a> for AI's sandboxes effectively. I feel like its really apt here (not sponsored lmao wish I was)<p>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.<p>Its really intuitive for what its worth, definitely worth a try <a href="https://github.com/quickemu-project/quickemu" rel="nofollow">https://github.com/quickemu-project/quickemu</a><p>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.
A coworker raised an interesting point to me. The CORS fix removes exploitation by arbitrary websites (but obviously allows full access from the opencode domain), but let's take that piece out for a second...<p>What's the difference here between this and, for example, the Neovim headless server or the VSCode remote SSH daemon? All three listen on 127.0.0.1 and would grant execution access to another process who could speak to them.<p>Is there a difference here? Is the choice of HTTP simply a bad one because of the potential browser exploitation, which can't exist for the others?
Neovim’s server defaults to named pipes or domain sockets, which do not have this issue. The documentation states that the TCP option is insecure.<p>VS Code’s ssh daemon is authenticated.
> Neovim’s server defaults to named pipes or domain sockets, which do not have this issue. The documentation states that the TCP option is insecure.<p>Good note on pipes / domain sockets, but it doesn't appear there's a "default", and the example in the docs even uses TCP, despite the warning below it.<p><a href="https://neovim.io/doc/user/api.html#rpc-connecting" rel="nofollow">https://neovim.io/doc/user/api.html#rpc-connecting</a><p>(EDIT: I guess outside of headless mode it uses a named pipe?)<p>> VS Code’s ssh daemon is authenticated.<p>How is it authenticated? I went looking briefly but didn't turn up much; obviously there's the ssh auth itself but if you have access to the remote, is there an additional layer of auth stopping anyone from executing code via the daemon?
> but it doesn't appear there's a "default"<p>From the page you linked: Nvim creates a default RPC socket at startup, given by v:servername.<p>You can follow the links on v:servername to read more about the startup process and figure out what that is, but tl;dr, it's a named pipe unless you override it.
[flagged]
If you have a localhost server that uses a client input to execute code without authentication, that’s a local code execution vulnerability at the very least. It becomes a RCE when you find a way to reach local server over the wire, such as via browser http request.<p>I don’t use VSCode you have mentioned so i don’t know how it is implemented but one can guess that it is implemented with some authentication in mind.
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??
Someone tell the AI labs to stop training on tutorial code.
Just run it in a sandbox, bro.
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!<p><a href="https://github.com/anomalyco/opencode/commit/7d2d87fa2c44e32314015980bb4e59a9386e858c" rel="nofollow">https://github.com/anomalyco/opencode/commit/7d2d87fa2c44e32...</a>
It seems like it was prior to 1.0.216?
It’s a vibe, bro.
Seems that OpenCode is YC-backed as well [0] [1]. I would've thought YC would encourage better cyber security practice than OpenCode have demonstrated here.<p>[0]: <a href="https://www.ycombinator.com/companies/sst">https://www.ycombinator.com/companies/sst</a><p>[1]: <a href="https://anoma.ly/" rel="nofollow">https://anoma.ly/</a>
Flock (YC S17) Hardcoded the Password for America's Surveillance Infrastructure 53 Times [0]<p>I have no idea where you got your internal image of YC-backed companies from, but it needs massive adjusting.<p>[0] <a href="https://news.ycombinator.com/item?id=46555807">https://news.ycombinator.com/item?id=46555807</a>
YC is not about anything but money.
move fast and break things culture
Wow and they have an Auth provider product too!
This is pretty egregious. And outside the fact the server is now disabled by default, once it's running it is still egregious:<p>> When server is enabled, any web page served from localhost/127.0.0.1 can execute code<p>> When server is enabled, any local process can execute code without authentication<p>> No indication when server is running (users may be unaware of exposure)<p>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.
The disclosure timeline is concerning.<p>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:<p><a href="https://github.com/anomalyco/opencode/issues/6355#issuecomment-3740105995" rel="nofollow">https://github.com/anomalyco/opencode/issues/6355#issuecomme...</a>
hey man, chill out.<p>everybody is vibecoding now, and dealing with massive security issues is bad vibes.
Lots of the same people that were behind: <a href="https://www.terminal.shop/" rel="nofollow">https://www.terminal.shop/</a><p>afaict, for that project they never went through PCI compliance. See original thread for more information: <a href="https://news.ycombinator.com/item?id=40228751">https://news.ycombinator.com/item?id=40228751</a><p>They seem to not have a lot of real world experience and/or throw caution to the wind and YOLO through security practices. I'd be weary using any of their products.
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.
<a href="https://github.com/opencode-ai/opencode" rel="nofollow">https://github.com/opencode-ai/opencode</a>
there was also the competing opencode which because crush done by charm.sh people.
You are either thinking of crush, roocode or kilo, they all started around the same time and dont have backing from major players yet.
If you aren't blocking your browser from allowing sites to call to local services, you should:<p>> Network Boundary Shield<p>> 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.<p>> 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).<p><a href="https://jshelter.org/nbs/" rel="nofollow">https://jshelter.org/nbs/</a>
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.<p>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.<p>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<p>[0] <a href="https://ampcode.com/" rel="nofollow">https://ampcode.com/</a><p>[1] <a href="https://github.com/charmbracelet/crush" rel="nofollow">https://github.com/charmbracelet/crush</a>
> They keep adding features without maintaining the core.<p>It does take a lot of discipline to review everything instead of pile on another feature, when it's so cheap to do.
Just looking at some other stuff in this page and it seems it may have a few SSRFs.<p>Also it uses astro 5.7.13 that may have an SSRF of it's own. No idea if would be exploitable, but way out of date packages with potential security risks are a good place to start looking.
The next few years are going to be a golden age for ops and security overtime
Cute you think those project teams won’t be outsourced to LLMs also.
wait, you're getting overtime pay?
I had an interesting experience with OpenCode yesterday, and I was also sent that RCE: <a href="https://taoofmac.com/space/blog/2026/01/12/1830" rel="nofollow">https://taoofmac.com/space/blog/2026/01/12/1830</a>
Seems `session/:id/shell` was also `session/:id/bash` and originally `session/:id/command` in some commits.<p>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.<p>(Several more commits under `wip: bash` and `feat: bash commands`)<p><a href="https://github.com/anomalyco/opencode/commit/7505fa61b9caa17f1ef358961d7e46beb3276ca9" rel="nofollow">https://github.com/anomalyco/opencode/commit/7505fa61b9caa17...</a><p><a href="https://github.com/anomalyco/opencode/commit/93b71477e6656005353ce8c71224a99170f4ae2f" rel="nofollow">https://github.com/anomalyco/opencode/commit/93b71477e665600...</a>
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.
Well I feel like they will take security more in context from here on out.<p>Atleast they didnt implode their communications like I see from some other companies.<p>To be really honest, when you bet on AI agents, I feel like soemtimes you bet on the future of the product as well which is built by the people so you are basically betting on the people.<p>I'd much rather bet/rely on people who are sensibile in communications in troubled times like this than who implode sometimes (I mean no offense to Coderabbit but this is what comes to my head right now)<p>So moments like these become the litmus test of the products basically imo by seeing how people communicate etc.
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.
fwiw they should probably slow down a bit, even though they seem to be winning the race. they started selling their own subscription plan last week, and promptly committed all subscriber’s emails to the public repo<p>> Hey - have some bad news.<p>> We accidentally committed your email to our repo as part of a script that was activating OpenCode Black.<p>> No other information was included, just the email on its own.
I was about to try it out, having heard good things.<p>But this leaves a very bad taste.<p>Guess I will stick to aider and copy-pasting.
Isn't it insane that any web page can run a port scan in the first place? Who wants that?<p>Meanwhile, running opencode in a podman container seems to stop this particular, err, feature.
> Silent fix<p>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.
Running a non deterministic model in your terminal, allowing it to run whatever commands it wants always seemed like such a fucking stupid thing to do to me. How can people just wing it, let alone when production code is involved is just baffling to me. 0 concern about security.
I run mine on the public internet and it’s fine, because I put it behind auth, because it’s a tool to remotely execute code with no auth and also has a fully featured webshell.<p>To be clear, this is a vulnerability. Just the same as exposing unauthenticated telnet is a vulnerability. User education is always good, but at some point in the process of continuing to build user-friendly footguns we need to start blaming the users. “It is what it is”, Duh.<p>This “vulnerability” has been known by devs in my circle for a while, it’s literally the very first intuitive question most devs ask themselves when using opencode, and then put authentication on top.<p>Particularly in the AI space it’s going to be more and more common to see users punching above their weight with deployments. Let em learn. Let em grow. We’ll see this pain multiply in the future if these lessons aren’t learned early.
Can you share what made this behavior obvious to you? E.g. when I first saw Open Code, it looked like yet another implementation of Claude Code, Codex-CLI, Gemini-CLI, Project Goose, etc. - all these are TUI apps for agentic coding. However, from these, only Open Code automatically started an unauthenticated web server when I simply started the TUI, so this came as a surprise to me.
I liked aider initially, but I keep running into problems, as the project seems largely unmaintained. I wanted to install OpenCode yesterday, but this somewhat turns me off. Are there any good model-agnostic alternatives? I am somewhat shocked there is not a lot of good open source CLI LLM code assistants going around.
I'd be curious to know what features need opencode.ai to be an allowed origin for the local server.
Related: <a href="https://news.ycombinator.com/item?id=46539718">https://news.ycombinator.com/item?id=46539718</a>
Why does an agent need a web server to take remote commands in the first place???
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.
people run AI tools outside a sandbox? tf? the first thing I did with claude code is put it in a sandbox.<p>come on people, docker and podman exist, please use them - it isolates you not only from problems like this but supply chain attacks as well.<p>it also has superior compatibility, any person working on your project will have all the tools available to compile it since to build & run it you use a simple Containerfile.<p>(rather outdated now: <a href="https://github.com/DeprecatedLuke/claude-loop" rel="nofollow">https://github.com/DeprecatedLuke/claude-loop</a>)
Vibe coding a coding CLI?
fwiw, maintainer of claude code has also said his december contribution for claude-code was 100% written by claude-code<p>which introduced so many bugs that people unsubscribed
If you want to have some fun check out aider.chat. They actually log how much of each version was built by aider itself: <a href="https://github.com/Aider-AI/aider/releases" rel="nofollow">https://github.com/Aider-AI/aider/releases</a>
This doesn't actually seem that bad to me? Browsers don't let random pages on the internet hit localhost without prompting you anymore so it's not like a random website could RCE you unless you're running an old browser—and at that point that's the browser's fault for letting web pages out of the sandbox. You shouldn't have to protect localhost from getting hit with random public websites.<p>The rest is just code running as your user can talk to code running as your user. I don't really consider this to be a security boundary. If I can run arbitrary code by hitting a URL I accept that any program running as me can as well. Going above and beyond is praiseworthy (good for you turning on SELinux as an example) but I don't expect it by default.
> Browsers don't let random pages on the internet hit localhost without prompting you anymore<p>No, that's a Chrome-specific feature that Google added. It is not part of any standard, and does not exist in other browsers (e.g. Safari and Firefox).<p>> The rest is just code running as your user can talk to code running as your user<p>No, that assumes that there is only a single user on the machine, and there are either no forms of isolation or that all forms of isolation also use private network namespaces, which has not been how daemons are isolated in UNIX or by systemd. For example, if you were to ever run OpenCode as root, any local process can trivially gain root as well.
How's that plastic utensils at Anthropic's buffet analogy going now?