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.
This question has been asked thousands of times since Clawd came around. Answer: it's an agent with tools, which means you define the boundaries and imagination is the limit. How is useful to you is defined by you. There might be lots of use cases for which you find it useful or none at all. It's subjective.
> 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.
Unfortunately title isn't visible on mobile. Extremely annoying to see a post that says "last month" and want to know if it was 7 weeks ago or 5 weeks ago. Some sites show title text when you tap the text, other sites the date is a canonical link to the comment. Other sites it's not actually a title at all l but alt text or abbr or other property.
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).
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.
My goal is to prevent Claude from blowing up my computer by erasing things it shouldn't touch. So the philosophy of my sanboxing is "You get write access to $allowlist, and read access to everything except for $blocklist".
I'm not concerned about data exfiltration, as implementing it well in a dev tool is too difficult, so my rules are limited to blocking highly sensitive folders by name.
Thank you for sharing a non-trivial working example of a sandbox-exec configuration. Having an exemplar such as what you have kindly shared is hugely beneficial for those of us looking to see what can be done with a tool such as this.
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.
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.
What are some actually useful use cases and how would I install them? This seems like the missing piece.
reply