DEV Community: sreeragh S

A Folder Shouldn't Be Able to Run Code Just Because I Opened It

sreeragh S — Sun, 13 Sep 2026 08:18:24 +0000

I came across a security bug recently that I haven't been able to stop thinking about, mostly because the bug itself is almost boring. There was no clever prompt injection, no model escaping a sandbox, and nobody convincing an AI to ignore its instructions through some weird encoded message. The model didn't even need to be contacted. You could open a project folder, your coding tool would run Git to understand the repository, Git would read some configuration, and suddenly someone else's code could be running on your machine.

The vulnerability class is called GitSpawn. Researchers at Manifold Security found eight related issues across seven coding agents, including Claude Code, Codex, Cursor, Goose, Hermes Agent, Qwen Code and Grok Build. One of the main paths involved core.fsmonitor, a legitimate Git configuration option that can point to an external program. Coding agents routinely run commands such as git status or git diff in the background to understand a repository, and those operations can cause Git to invoke the configured helper. In vulnerable versions of these tools, that could happen outside the agent's sandbox and without the approval prompt you'd normally expect before something executes on your machine.

I think the interesting part isn't really that an AI coding tool had a security vulnerability. Software has vulnerabilities all the time. What interests me is that somewhere along the way we've made opening a folder surprisingly close to executing a program.

Repositories aren't really just folders anymore

I think most of us still have an old mental model of a repository. It's a directory containing source files. You can open it, look around, search for something, maybe change a few files, and nothing should actually happen until you deliberately run the software. That model hasn't really been true for a while.

Open a modern project and quite a lot can happen automatically. Your editor starts extensions and language servers, Git commands run in the background, files get indexed, formatters discover configuration, development environments get detected and various tools begin trying to understand what kind of project they've been dropped into. Most of this is incredibly useful. I definitely don't want to manually explain my repository to every tool I use.

The problem is that repositories increasingly contain instructions for the tools inspecting them. A project can have editor settings, tasks, formatter configuration, package scripts, development containers, compiler plugins, CI configuration and plenty of other things that aren't really source code in the traditional sense. Some of those eventually point to executable programs.

VS Code has had Workspace Trust for years for basically this reason. Its Restricted Mode limits things like tasks, debugging, workspace settings, extensions and terminals when you open unfamiliar code. The interesting thing about that feature is what its existence implies: simply browsing a repository is no longer obviously a passive operation.

We've slowly turned a repository from a collection of files into a description of an entire development environment. That's incredibly convenient, but it also means the security boundary has changed without our mental model necessarily changing with it.

Convenience keeps eating the boundary

Most automatic developer tooling exists for completely reasonable reasons. When I open a project, I want my editor to immediately know what language it uses. I want Git state available without asking for it. I want my formatter configured correctly, my imports understood and my coding agent to know which files I've modified before I even start explaining the problem.

Having to manually configure all of this every time would be ridiculous, so tools automatically inspect more things. Then they inspect a little more. Eventually "understand this repository" means running a collection of commands, loading configuration and starting processes, some of which are influenced by the repository being inspected.

That's where things get weird because we normally think about security in terms of explicit execution. Don't run random shell scripts. Don't install binaries you don't trust. Don't paste a command from a random website into your terminal without understanding it. Those rules are easy enough to understand because there is a visible moment where you decide to execute something.

There is another category that's much harder to reason about: software executing something while apparently trying to inspect something else. git status feels like a read operation. In the GitSpawn case, however, repository-controlled configuration could cause that seemingly harmless operation to invoke another program. The command itself wasn't really the problem. The trust relationship around the command was.

AI made an old problem much easier to see

GitSpawn naturally gets described as an AI security problem because coding agents exposed the vulnerability, but I think that's slightly misleading. The model wasn't really doing anything interesting here. The vulnerability existed in the plumbing underneath it. In several cases, the dangerous command could execute while the agent was gathering context, before the normal model-driven tool flow had even started.

What AI changes is how autonomous developer tools are becoming. Instead of waiting for me to click something, the software looks around on my behalf. It reads files, runs commands, checks Git state, launches subprocesses and builds a mental picture of the project before I have even decided exactly what I want it to do. That's what makes these old assumptions more dangerous.

A behaviour that was reasonably safe when a human deliberately invoked it might not be safe when an agent automatically invokes it against arbitrary input. A configuration option that's perfectly useful when I created it myself becomes very different when it arrived inside a folder somebody sent me.

None of the individual pieces necessarily changed. The way we're composing them did. I suspect we'll keep finding bugs like this because we're taking developer tools designed around a human being in the loop and putting them underneath systems designed specifically to remove the human from more and more of that loop.

"Read-only" probably needs a better definition

I've started thinking that developer tools need a stricter idea of what inspecting a project actually means. If I'm opening an unknown repository because I want to understand what's inside it, the safest version of that operation should be extremely boring. Read files, parse text, inspect metadata and maybe build an AST. None of that should require trusting the project.

The moment inspection starts executing repository-defined hooks, invoking arbitrary binaries, evaluating executable configuration, loading plugins or starting shells, I don't think we're really inspecting anymore. We're executing things as a side effect of inspection.

This gets difficult because modern developer tooling is basically built out of composition. Git calls hooks. Editors call formatters. Formatters read configuration. Language servers invoke compilers. Compilers load plugins. Package managers run lifecycle scripts. Shells load environment configuration. Every one of those behaviours can be completely reasonable on its own, and then two tools get connected in a way where one assumes the other's normal behaviour is safe.

Security boundaries often disappear in those gaps.

Maybe the better mental model for a repository is something closer to a document containing macros. A document looks like data until the document itself starts containing instructions for the software opening it. At that point, "open this" and "trust this" need to become separate operations.

Source repositories increasingly look like that. They aren't just source code anymore. They can describe editor behaviour, build environments, containers, package scripts, CI pipelines and instructions for autonomous tools. They're partially data and partially executable environment. Treating an unfamiliar repository as inherently safe because "I haven't run the code yet" doesn't make much sense anymore.

Sandboxing needs to start before the agent does

One of the things I found most interesting about GitSpawn is that some of the affected tools already had permission systems or sandboxing. The problem was that the dangerous behaviour could happen while the application itself was preparing the session. If repository-controlled code executes before the sandbox or approval boundary becomes relevant, having a really good sandbox afterward doesn't help much.

That's probably the architectural lesson here. Security can't begin when the model decides to call a tool. It has to begin when untrusted input enters the system.

If an application opens an unfamiliar repository, everything automatic after that point probably needs to assume the repository is hostile until the user decides otherwise. That might mean sanitized Git operations, disabled hooks, restricted configuration and a genuinely passive inspection mode. It's less convenient internally, but the security model becomes much easier to understand.

I still want all of this tooling to be automatic. I don't want to manually run git status, start my language server, configure my formatter and explain the repository structure every time I open a project. Automatic context is fantastic, and coding agents would be dramatically worse without it.

I just think we're reaching the point where the convenience has become powerful enough that the security model needs to catch up. The safest software used to be software that didn't execute random programs. Now we're deliberately building tools whose entire purpose is to execute programs for us, which is fine, but there should still be a meaningful distinction between looking at something and trusting it.

A folder should be allowed to tell my tools what it contains. I'm less convinced it should be allowed to tell them what to run.

Open Source Is About to Matter More Because of AI

sreeragh S — Mon, 07 Sep 2026 22:48:04 +0000

Why AI could make software ownership, forking, and open-source trust more valuable than ever.

I’ve been thinking about something slightly weird lately. AI is making software cheaper to build. Not cheaper in the AWS sense, but the actual act of sitting down and turning an idea into working software. Things that would’ve taken me a week sometimes take a day now, and things I probably wouldn’t have bothered building at all become random evening projects because I can ask an agent to do most of the boring parts.

And I think this is only going to get more extreme. We’re probably heading towards a world where producing software isn’t particularly expensive anymore. At first I thought this would make open source less important. If anyone can recreate software, who cares if the original is open source? But the more I think about it, I think the opposite might happen.

Code is becoming cheap

For most of software history, code itself was expensive. You needed people who knew how to write it, those people needed time, and companies spent ridiculous amounts of money turning requirements into working systems. If somebody spent three years building a complicated product, recreating it wasn’t as simple as looking at the UI and asking an agent to make another one.

That assumption is starting to break. Obviously AI cannot perfectly recreate every complicated piece of software today. There is still an enormous difference between generating something that looks correct and maintaining something that actually works. But the direction seems pretty obvious. The amount of software one person can produce is increasing very quickly, and the cost of just trying an idea has collapsed.

And when the cost of producing something collapses, usually the valuable part moves somewhere else.

Maybe the valuable thing isn’t the code anymore
I’ve been building Zilobase, an open-source workspace, and this question comes up in my head a lot. What does being open source actually mean if an AI can eventually recreate most of the implementation anyway?

I don’t think the answer is just that you can see the code. That’s useful, obviously, but it feels increasingly incomplete. The more interesting part is that I can own the thing. I can run it, change it and keep using it even if the original maintainer disappears tomorrow. If somebody makes a product decision I absolutely hate, I can fork it. If a company gets acquired and the new owner decides the $10 plan should suddenly cost $40, the software itself hasn’t been taken away from me.

That’s a very different relationship from most software we use today. We don’t really own much software anymore. We rent access to it. And AI might make that distinction much more obvious.

Renting software made sense when rebuilding it was expensive
SaaS made an enormous amount of sense because operating software is annoying. Someone else hosts the database, deploys updates, fixes servers, manages backups and gives you a login. You pay $20 every month and don’t think about any of it. That’s a pretty good deal.

But there was another reason SaaS businesses were defensible: rebuilding the software was difficult. If a company had 40 engineers working on a product for five years, you weren’t going to casually recreate it because they increased the price. You either paid them or moved to another company that had also spent years building something similar.

AI changes that equation a little. Imagine a product you really like gets acquired. The new company removes three features, adds AI to the name and doubles the price. Today you complain on Twitter and eventually pay them anyway. But what happens when somebody can fork the last open version, ask an agent to implement the missing features and have a usable alternative running a week later?

That’s a very different kind of leverage.

Forking is going to become much more interesting
Forking has always been one of my favourite ideas in open source. Not because everyone actually does it. Most people don’t. It’s because you can.

The problem is that historically maintaining a serious fork was expensive. Imagine a project with hundreds of thousands of lines of code. You disagree with the maintainers, so you fork it. Great. Now congratulations, you own hundreds of thousands of lines of code that you have to understand and maintain forever. That’s not exactly freedom for most people.

AI changes the economics here too. Coding agents are getting much better at navigating unfamiliar repositories, making changes across large codebases, writing tests and explaining parts of systems you haven’t seen before. Suddenly maintaining a fork doesn’t necessarily require understanding every corner of the original project yourself.

It still requires judgement. It still requires someone who actually cares whether the thing works. But the amount of human effort required could become dramatically smaller, and I think that makes the right to fork much more powerful than it used to be.

Open source also changes what we can trust
There’s another part of this that I didn’t think about much until AI. We’re increasingly putting software in places where the software isn’t just storing data anymore. It’s reading our email, looking through our documents, writing code, executing tools and talking to other systems on our behalf.

At that point, “trust us” starts becoming a slightly uncomfortable security model.

Being able to inspect, modify and run the system yourself starts mattering a lot more. I think we’ll increasingly start asking questions like: Can I see what this agent is doing? Can I change it? Can I move my data somewhere else? Can I run it without asking the company that created it?

And probably the most important one: what happens if this company disappears tomorrow?

AI doesn’t kill open source
I think AI actually makes the reason for open source clearer. Open source was never valuable only because programmers could read the implementation. It was valuable because nobody had complete control over what happened next. You could take the thing and continue.

For a long time that ability was mostly theoretical for normal users because modifying serious software required serious engineering resources. AI might make that ability much more practical. If implementation becomes cheap enough, then source code itself stops being the moat. The community matters. The ecosystem matters. The decisions behind the product matter. The people maintaining it matter. And the ability to take the project somewhere else matters.

Maybe we’re heading towards a strange world where software becomes almost disposable but ownership becomes incredibly important. Anyone can make the code. The interesting question becomes whether you’re allowed to do anything with it.

I think that’s a pretty good reason to keep building things in the open.

Understanding Things Anyway

sreeragh S — Sun, 06 Sep 2026 00:48:38 +0000

I’ve been noticing something weird lately. Not with AI itself. AI is obviously getting better: the models are getting better, the tooling is getting better, and things that sounded completely ridiculous two years ago are now normal things to do on a Tuesday.

I’m talking about the people talking about it. Spend enough time on Tech Twitter and you start seeing the same ideas over and over again, just with different words.

Someone discovers that an LLM can call a tool: it’s an agent. Someone puts two agents together: it’s multi-agent orchestration. Someone gives the agent memory: it’s cognitive architecture. Someone lets it modify its own files: it’s autonomous software engineering.

Then somebody draws a diagram with twelve boxes and suddenly we’ve apparently invented computers again. The funny thing is that most of these things are genuinely useful. The problem isn’t the technology. It’s the mythology around the technology.

Understanding is still the work

There seems to be a growing belief that because AI can do something, understanding that thing is no longer necessary. I’ve seen people genuinely argue that you don’t need to learn programming anymore because AI can write code; you don’t need to understand databases because an agent can work with PostgreSQL; you don’t need to understand frontend development because AI can generate a UI; and you don’t need to understand infrastructure because an agent can deploy it.

At some point, you don’t need to understand anything because there is an API for everything. I’m not sure what we’re optimizing for at that point. If the goal is simply to produce software, then sure, this is fantastic. But if the goal is to become someone who can build software, I don’t think skipping all the fundamentals gets you there.

There is a difference between not doing something and not knowing how something works. I don’t manually manage memory in every program I write, but that doesn’t mean I don’t want to understand memory. I don’t write HTTP servers from scratch every time, but that doesn’t mean I don’t want to understand HTTP. I don’t implement a database engine before building an application. That would be insane.

Abstractions are good. That’s what software engineering has always been about: we build things on top of other things so that we don’t have to think about everything simultaneously. The problem starts when the abstraction becomes so opaque that you don’t know what to do when it breaks. And everything breaks.

AI is particularly good at hiding this problem. You can ask it to build something and get back a surprisingly good application. Sometimes it is actually excellent. The first time you experience this, it feels like magic: you describe what you want, and a few minutes later there is a working application sitting in front of you.

It’s easy to make the next mental jump: “If it can do this, maybe I don’t need to know how any of it works.” That’s the trap. Because the application working once isn’t the same thing as the system being understood.

The difficult part of software usually isn’t getting the happy path to work. It’s everything around it: what happens when two requests arrive at the same time, when the network disappears, when the database is slow, when the user has ten million records, or when your third-party API changes its response? What happens when the model confidently invents an API that doesn’t exist, or when your bill goes from $40 to $4,000?

The machine is very good at producing the first version. I’m still not convinced we’ve solved the second part.

What the internet rewards

And then there’s the startup problem. Open enough AI startup websites and they start blending together: some sort of black background, a large statement about the future, and a chat interface. “Your autonomous AI workforce.” “AI employees for every business.” “Agents that actually get work done.” Maybe there’s a little animation showing several colorful circles talking to each other.

And then the pricing page: $20 per seat. Enterprise: Contact us.

I don’t think these companies are necessarily bad. Some of them will probably become enormous. But the sheer number of companies doing roughly the same thing is interesting. AI has made software incredibly cheap to produce. That sounds entirely positive until you realize that everyone now has the same advantage.

If everyone can build a product in a weekend, the product itself becomes less interesting. The difficult question becomes: Why this product? And that’s a much harder question to answer with an LLM.

This is where I think social media makes the problem worse. The internet doesn’t reward understanding very well; it rewards things that are easy to understand quickly. A detailed explanation of why a distributed system fails under a particular workload isn’t going to outperform:

“SOFTWARE ENGINEERS ARE FINISHED.”

The second one gets clicked. People argue about it, someone screenshots it, someone makes a response video, and then someone else writes a thread explaining why the original person is wrong. Now there are twelve pieces of content where previously there was one bad opinion. The machine is fed. Everyone wins—except the person who wanted to learn something.

I’ve started noticing that the people I actually learn the most from rarely make the biggest claims. They’ll say, “I tried this. It worked surprisingly well. Here’s where it broke. Here’s the benchmark. Here’s the repository. Here’s what I’d do differently.”

That’s it. No prediction that an entire industry is dead, no grand theory about the future of human intelligence, and no diagram explaining why their three-agent startup is the next operating system. Just evidence. It’s almost boring, which is probably why it doesn’t do very well online.

Use the machine, keep the curiosity

I also don’t think the answer is to become anti-AI. That seems equally stupid. I’m using AI constantly. It’s one of the best tools I’ve ever had as a developer.

I can throw an unfamiliar codebase at it and get a decent explanation. I can prototype something in an afternoon that would have taken me days before. I can use it to write repetitive code, investigate errors, explore an API, generate tests, and get unstuck when I’m staring at something stupid for too long. That’s incredible. I don’t want to go back.

I just don’t want to confuse using a tool with outsourcing your understanding to the tool. Those are very different things.

Maybe the real shift isn’t that programming is disappearing. Maybe programming is becoming less about writing code and more about knowing what the code means. That would actually be a pretty good future.

Let the machine write the boring stuff. Let it generate the first draft. Let it handle the repetitive parts. But keep the ability to open the hood: read the code, read the logs, look at the database, understand the network, question the output, and throw the whole thing away when it’s built on the wrong assumption.

That’s still engineering. And I suspect it will remain engineering for quite a while.

The thing I find most uncomfortable about the current AI conversation is that we’re starting to treat curiosity as inefficient. Why learn how something works if an agent can figure it out? Why read the documentation if you can ask the model? Why understand the system if the model can operate it?

Because sometimes I want to know. That’s reason enough.

You don’t learn how computers work because you expect to manually flip bits for the rest of your life. You learn because understanding the machine changes what you’re capable of doing with it. That’s the part I don’t want to lose.

AI can make me faster. It can make me more productive. It can probably make me a better programmer. But if using it eventually makes me less curious, less willing to understand things, and more comfortable accepting answers I can’t verify, then we’ve made a strange trade. We’ve made the computer more capable while making the person operating it less capable.

I don’t think that’s progress. I think the interesting future is somewhere else: use the machine, let it do more, and learn more anyway.

And when somebody tells you that you don’t need to understand something anymore because AI can do it for you, the correct response might simply be:

Cool. Now show me how it works.