It does some merge magic so that PR B shows the correct diff; and does so without needing to force push, so on your side you can just "git pull" and continue working.
Of course I expect this repo to become obsolete when GitHub makes their native stacking public.
That it's it's better to publish the garbage data than to not publish it though. I would worry about complaining too much lest they just decide to stop publishing it because it creates bad PR.
The point is authorization. With full web access, your agent can reach anything and leak anything.
You could restrict where it can go with domain allowlists but that has insufficient granularity. The same URL can serve a legitimate request or exfiltrate data depending on what's in the headers or payload: see https://embracethered.com/blog/posts/2025/claude-abusing-net...
So you need to restrict not only where the agent can reach, but what operations it can perform, with the host controlling credentials and parameters. That brings us to an MCP-like solution.
Well, Graphite solves the problem of how to keep your stack of GitHub pull requests in sync while you squash merge the lowest pull request in the stack; which as far as I know jujutsu does not help with.
The problem I have had with this type of app is that, on Instagram at least any video that a friend posts is considered a reel. And I want to watch videos that my friends post. What I don't want is swiping mindlessly through random videos. So really I would like a swipe blocker not a short video blocker. (And bonus points if I could make it work on Firefox)
On the one hand, yes this has obviously high immediate value; on the other hand, I can't help but feel like you are giving access to multiple tools that can be used for arbitrary code execution anyway (i.e. running tests, installing dependencies, or running any linter that has a plugin system...), so blacklisting `git --exec-path=/bin/sh` for example is... Misguided? You would have a better time containing the agent in an environment without internet access?
I have an actual oven where I can select "programs".
As far as I can tell, they control three parameters:
* Where the heat comes from (top, bottom, or both)
* Whether or not ventilation is activated
* The temperature
There is also a dial for temperature, but not for the other two parameters. I am not sure whether every combination is covered by the "program" dial. I am not sure whether or not my understanding is even correct.
I would say it's an 7.5 out of 10 on the nightmare bicycle scale.
The README fails to address the elephant in the room, which is that usually shell scripts mainly call external commands; as far as I can tell there is no documentation of which built-ins are supported?
That said, in a similar vein, you could probably create a bundler that takes a shell script and bundles it with busybox to create a static program.
In France, training cars have only one steering wheel, and the instructor is perfectly able to drive the vehicle by steering with his extended left arm.
I guess everyone is different and appreciates a different amount of collaboration!
I guess something ideal for me would be roughly 70% pair programming, 30% alone time - but I have not been able to test this guess because I have always worked on teams where pair programming is the exception, not the norm.
All the toilets in Paris self-clean between users. You don't need the sensor to work not to get sprayed, just to exit the toilet when a voice says "EXIT THE TOILET NOW, THE SELF CLEANING PROCESS IS ABOUT TO BEGIN.
The thing the author has never experienced is someone accidentally implementing an existing interface, and then code expecting this interface to call that accidental implementation in a way that creates a bug.
It does some merge magic so that PR B shows the correct diff; and does so without needing to force push, so on your side you can just "git pull" and continue working.
Of course I expect this repo to become obsolete when GitHub makes their native stacking public.