CGamesPlay

Sure, it's for those customers who don't have any idea what a "context window" is.

No, that link goes to the second “download our app” screen shown in the OP.

This is untrue. Subpoenas, wiretapping, and other extrajudicial means can be stopped by legislation that bans them. You can't say in one breath that legislation that enables it (Patriot Act) cannot be undone by more legislation. There are many hurdles required to produce the required legislation, which may not even be broadly supported by the public, but it isn't correct to say "no amount of legislation can stop existing legislation".

Certainly not. Pi is "minimalist", so the draw is that it's "easy" to set it up yourself. You can not do that and run it in yolo mode, and you can do that with Claude Code too. Heck you can even use this hypothetical real-sandbox-with-interactive-prompts with Claude Code instead, once you build it.

Back to my original point: Claude Code gives you a false feeling of security, Pi gives you the accurate feeling of not having security.

Well, you are imagining a worse UX, but it doesn't have to be. Pi doesn't include a sandboxing story at all (Claude provides an advisory but not mandatory one), but the sandbox doesn't have to be a simple static list of allowed domains/files. It's totally valid to make the "push code" tool in the sandbox send a trigger to code running outside of the sandbox, which then surfaces an interactive prompt to you as a user. That would give you the interactivity you want and be secure against accidentally or deliberately bypassing the sandbox.

To me, the most interesting thing about Pi and the "claw" phenomenon is what it means for open source. It's becoming passé to ask for feature requests and even to submit PRs to open source repos. Instead of extensions you install, you download a skill file that tells a coding agent how to add a feature. The software stops being an artifact and starts being a living tool that isn't the same as anyone else's copy. I'm curious to see what tooling will emerge for collaborating with this new paradigm.

> if I start the agent in ./folder then anything outside of ./folder should be off limits unless I explicitly allow it, and the same goes for bash where everything not on an allowlist should be blocked by default.

Here's the problem with Claude Code: it acts like it's got security, but it's the equivalent of a "do not walk on grass" sign. There's no technical restrictions at play, and the agent can (maliciously or accidentally) bypass the "restrictions".

That's why Pi doesn't have restrictions by default. The logic is: no matter what agent you are using, you should be using it in a real sandbox (container, VM, whatever).

4 times in one thread, please stop spamming this link.

Thanks for putting this together, it's very helpful.

Readers may also be interested in <https://github.com/eugene1g/agent-safehouse> which was open sourced after a recent HN conversation <https://news.ycombinator.com/item?id=46923436>.

You can rename `.gitkeep` to `.gitignore` and both be happy in that case.

Wow, the original was actually the real diagram at a thumbnail-quality resolution, so this was an AI upscaling or something like that.

https://github.com/MicrosoftDocs/learn/blob/c266367ec0eb1f7f...

From a brief look, this appears to be using LLM-as-optimizer techniques to generate and measure the impact of skills. That's a lot more involved and likely more effective than the typical "ask Claude to write a skill for the task it just did".

> Using gskill, we learn repository-specific skills for jinja and bleve with a simple agent (Mini-SWE-Agent, gpt-5-mini), boosting its resolve rate from 55% to 82% on Jinja and from 24% to 93% on Bleve. These skills also transfer directly to Claude Code: on Bleve, Claude Haiku 4.5 jumps from 79.3% to 100% pass rate while running faster; on Jinja, Claude Haiku 4.5 improves from 93.9% to 98.5%.

My instinct is that it should be built in to tool calls. So if there was a "klaw dispatch tool", it would have the same approval flow as the "publish draft" tool, which is to say some easy way for a human to review and approve (or provide feedback).

This looks like what I want. A few questions: is it possible to have a “mayor” type role that has the ability to start other agents, but at the same time be unable to access those secrets or infiltrate prompt data? The key piece I don’t see is the agent needs a tool for klaw itself, and then I have to be able to configure that appropriately.

Is there a unified human approval flow, or any kind of UI bundled with this? Maybe I missed this part.

But what can it actually do? I read the landing page, your blog post, glanced through the docs… lots of stuff about how it’s built and absolutely nothing about how it’s useful to me.

What are some actually useful use cases and how would I install them? This seems like the missing piece.

> Github doesn't show timestamps in the UI, but they do in the HTML.

Unrelated tip for you: `title` attributes are generally shown as a mouseover tooltip, which is the case here. It's a very common practice to put the precise timestamp on any relative time in a title attribute, not just on Github.

Claude has built-in support for those OSCs, no extra software needed. But you don't get the custom sound pack with those (at least without more extra software on the OS/terminal side).

If you want this to work over SSH, you'll need a different approach. I wrote an article about getting sounds from iTerm2 over SSH a while back: https://cgamesplay.com/post/2020/11/25/iterm-plugins/#playin...

Then it's just a simple Claude code hook to play whatever sound: https://github.com/CGamesPlay/dotfiles/blob/0fd07aea4863b581...

In case you missed the several links, exe.dev is his startup which provides sandboxing for agents. So it makes sense he wants to get people used to paying for agents and in need of a good sandbox.

I do this, and routinely shadow commands with my own wrappers to do things like set environment variables.

And then there’s Claude. It deletes whatever it finds at ~/.local/bin/claude, so I have to use a shell function instead to invoke the full path to my wrapper.

This is just an ad hominem attack. Doesn't seem like the author is "in over their head"; they seem to have a pretty solid grasp of actual identifiable gaps between implementations and various specs, and the article was written with the same kind of "chastising" tone as you would see from any grey-bearded hacker who's unsatisfied with the way things are.

You say this, but the opposite is equally true. Why should I trust the CIA's website when it says that there are no penguins in Greenland, and so there's no ecological harm to strip mining the place?

From the posts, it sounds like the original maintainer was approaching the point where they'd just abandon it, so this overall seems like a better outcome than either abandonment or sale to a PE firm.

I'm not aware of any CLI arguments that accept emdash for long arguments–but I'm here for it. "A CLI framework for the LLM era"

For me the ideal case is three-state. When run interactively with no flags, print a dry run result and prompt the user to confirm the action; and choose a default for non-interactive invocations. In both cases, accept either a --dry-run or a --yes flag that indicates the choice to be made.

This should always be included in any application that has a clear plan-then-execute flow, and it's definitely nice to have in other cases as well.

> we in America would love to see Europe break free of its suicidal regulatory straitjacket and do enough innovation and building to carry its own weight

This is false. Europe innovating and "carrying its own weight" means less market share for American companies, less American middlemen tapping into money moving throughout the European economy, less ability for American intelligence agencies to access European information, and less soft power from the threat of cutting off American technology.

> I then gave both proofs to Opus and it confirmed their equivalence.

You could have just rubber-stamped it yourself, for all the mathematical rigor it holds. The devil is in the details, and the smallest problem unravels the whole proof.

For reference, the MIT license contains this text: "Permission is hereby granted... to deal in the Software without restriction, including without limitation the rights to use". So the README containing a "Prohibited Use" section definitely creates a conflicting statement.

Honestly, I'm a big Claude Code fan, even despite how bad its CLI application is, because it was so much better than other models. Anthropic's move here pretty much signals to me that the model isn't much better than other models, and that other models are due for a second chance.

If their model was truly ahead of the game, they wouldn't lock down the subsidized API in the same week they ask for 5-year retention on my prompts and permission to use for training. Instead, they would have been focusing on delivering the model more cheaply and broadly, regardless of which client I use to access it.

He put a fuse on every individual cell and on the overall unit, so I would say he was reasonably cautious (although he deployed a bunch of high-voltage exposed wires at the end of the video, but we can assume that was just a tech demo).