lucideer

I think this is a case where it's a net positive to have both. If Codeberg's opinionated mission isn't aligned with your personal approach to code, you definitely shouldn't host there, but it's genuinely hugely valuable that it exists for those who do share their vision. Both approaches can coexist & it seems net positive to have that diversity of services available.

In terms of the risk of data loss -notwithstanding that having any codehost as your sole storage location without backups seems unwise for anything you value - Codeberg's approach to handling ToS violations has to date been extremely personal & not overly automated, so it's reasonably safe to assume artifacts won't be deleted without appropriate notice.

You're definitely referring to fully autonomous harnesses as I suspected - these are generally quite well suited to VM deployment (quite possibly in the cloud) if you're concerned with sandboxing as they don't typically run into the same challenges as an interactive LLM UI.

For ad hoc task/investigation-oriented fully interactive agent UIs the requirements are more complex & there's all a lot of advantages to running locally on host, but e.g. for builds & testing in that context there's less of a requirement for the LLM to have full control over every execution given user presence. Basically the use-case being discussed here is LLMs-as-assistance/pair programmers/active digital colleagues, rather than fully automated autonomous harnesses (legit but separate use-case).

It might be overused elsewhere but I don't think its use here is inappropriate given it's qualified: it doesn't say "frontier models", it says "frontier open models".

That's a pretty oddly narrow & specific definition of what LLM harnesses are for & it certainly doesn't match my experience. In fact I'm genuinely struggling to think of any scenario where an agent CLI would need to execute a build artifact. Sure many devs might ask it to for convenience of not having to spend 3 seconds typing & running the command themselves but I can't see it ever being explicitly necessary.

I will note you used the term "harness" which - while terms around LLM tooling is still inconsistently defined - in my experience generally pertains to agentic automations: e.g. LLM CI integrations, etc. Rather than interactive local tooling like OpenCode. So maybe you're referring to that (though even then I still can't think of examples)

allowlists are not there for security

I don't honestly believe that the allowlist isn't (naively) intended to be there for security. It's certainly not a very useful ux for providing LLM guidance: prompts, memories & AGENTS.md already provide an avenue for this & having it in a formalised, structured format isn't conducive to LLM guidance. The implementation brings in a lot of dependencies (tree-sitter) & contains enough complex targeted string parsing that's definitely superfluous for something intended to be fed to an LLM as guidance. Perhaps most importantly - the LLM behaviour on encountering limits of the allowlist is neither intuitive nor consistent enough to be considered reliably guiding (& system prompt doesn't do anything to mitigate this).

I don't expect them to be built into my LLM harness because I value modular software composition

I value software modularity, in particular where software architecture is concerned, but I wouldn't go as far as being prescriptive about the unix philosophy. Direct integration does have its pros, & most of the cons associated with it in practice are specific to bad architecture (or black box software). For example Claude cli does integrate sandbox-exec internally, but it does do in a closed-source inaccessible way that negates its value. I am confident it can be done well though, even if I'm somewhat less confident that it ever will be.

It's an allowlist so not-git would be disallowed by default. Renaming it to a binary that is already listed in the allowlist should fail due to a cryptographic binary signature mismatch.

I've used VMs because dealing with tool access is infinitely simpler & less fraught than tailoring sandbox profiles, but ultimately using sandbox-exec has yielded better workflows (if & when I've gotten an appropriate profile stood up). The sandbox tends to have a lot more rough edges than the VM, so I do switch back & forth between VM & sandbox, but I suspect a good sandbox-wrapping implementation with nice ux is the future.

Perhaps one could go further & combine them: e.g. a sanbox-wrapped on-host CLI that subshells/subagents out to VMs on demand. Seems potentially overcomplicated but I guess one can dream.

This is very doable - it's a shell you're creating within the cli so you have a lot of control over the environment. If you look at tools like sandbox-exec & apparmor, they specifically target binaries, not string input. E.g. if I write a bash script & put it in my path, OpenCode's allowlists aren't looking at the commands my bash script is exec-ing, nor monitoring subshells it creates. A proper sandbox has full context of the execution chain. Not only that, it's potentially much more powerful & expressive in that you can allowlist indirect filesystem access from commands run.

For example, I recently ran opencode via sandbox-exec & naively granted the sandbox access to the aws cli. First attempt to exec it failed because I hadn't granted the sandbox access to the credential file in ~/.aws. This took 2 seconds to resolve but effectively highlights how utterly useless the tree-sitter string-parsing they're doing is. It's so concerning because implementing tree-sitter for that is non-trivial to the point that any competent dev should surely realise quickly while implementing it that this avenue is utterly useless. Yet every high-profile agent cli has taken this approach.

I've run agentic CLIs in a sandbox (using MacOS sandbox-exec) & in VMs - both solutions have an inherent advantage over any integrated sandboxing by virtue of their independence (even before we get into configurability). Claude CLI integrates sandbox-exec internally, but I can't really trust it completely because Anthropic don't really have any vested interest in restricting their own tooling on my machine - they want me to rely on the tooling more, not less, which naturally entails granting the tool broader access: this is reflected in two ways in their sandbox-exec implementation: (1) it's wrapped in a relatively lax default profile & (2) not everything the cli does is sandbox-wrapped.

All that said, I don't think I'd agree that sandboxing doesn't belong in the agent harness. Ultimately, I want to be using an open source cli tool that doesn't come with the above Anthropic perverse incentives. The advantage of using a separate sandbox solution with Claude CLI isn't that it's separate, it's that I control it. Ideally I should control my agentic cli though, & in that context, bundling the sandbox comes with a lot of inherent advantages.

Unfortunately, as far as I've seen, the current batch of open source clis are pretty poor at the above, leaving little incentive to switch from proprietary solutions.

- Sensible permission system - when the agent runs git diff && rm -rf /, what do you think will happen in your current coding agent? It will treat it as git *. Maki uses tree-sitter to parse the bash command and figure out the permissions requested are git * and rm *. Disable using --yolo.

This sounds identical to what OpenCode does (&, contrary to their own marketing, does not seem sensible at all).

The fact that this mechanism is so primitive across all agentic clis is frankly a serious indictment of the competence & experience behind LLM-focused development teams.

This is a security issue that has in the past been solved via explicit file-path-based allowlisting, & more recently - due to file-path matching being deemed insufficiently secure - apps have been switching to cryptographically signed binary matching as a more modern alternative to the less secure path matching. In that context, the fact these recently-written "modern" agentic clis are using a method that's more basic & even less secure than the "old insecure" method most apps use is pretty shocking.

I agree generally but I'd moderate this to say this is an "anti- the current state of AI" post insofar as none of the issues listed are inherent to LLMs, they just seem to be ubiquitous in the current generation of agentic CLIs. I'm not aware of any CLI that doesn't have the listed severe issues, but I could certainly write a CLI myself (if I had the time & energy) that avoided these issues.

Good to see Codex as a datapoint: I haven't used it. I can confirm though that this is certainly what Claude does, with the addition that Claude's adherence to its own string-match based allowlist seems even less deterministic than OpenCode's.

This is a good summary of the dangers of using agentic clis, but the title & general focus on opencode is odd for two reasons:

1. Most obviously & importantly this is a complaint without a straightforward suggested alternative. A sibling commenter mentions suggesting fixes to Opencode would be more productive: I don't necessarily agree since many of these issues are fundamental & would likely require an almost ground up rethink & rewrite, but the issue is that the article contains no constructive proposal at all: it may as well be titled "Stop Using LLMs"

2. None of the major issues listed are unique to OpenCode. At least the full list within the "Alarming Things" seems in my mind to apply to Claude CLI, & I would guess most other agents from frontier model providers.

Granted it's worthwhile documenting these issues as a plea for someone to build better tooling from the ground up, so the article is far from worthless - on the contrary I've bookmarked it & will be sharing & referencing it widely & often. But the title & focus is just very odd & seems misguided, especially when the contents of the piece is otherwise so good.

This is a generally great article with a lot of truths, but the title & overarching narrative throughout is a little off & feels like the author is trying to shoehorn one story into another.

In truth, the phenomenon they're describing (very accurately might I add) doesn't lead to the company "going blind" - the company never had eyes to begin with. The company was incepted in the cave & has no need to apoptose an organ that never needed to exist: neither in the company in abstract nor in its "engineers who have never worked elsewhere [...] well-meaning people who do not suspect anything is off. They have only ever known the cave"

The apoptosis the article describes doesn't really affect the company per se - its a process only new joiners undergo, part of their subsumption into The Company. Or they resist & ultimately leave, reinforcing the concentration of blindness.

---

Or, if they don't either submit to apoptosis or leave the company, they do a secret third thing, possibly the most common reaction: they silo. That can lead to some rare gems emerging from otherwise stagnant companies but mostly leads instead to team isolation & further stagnation.

I'm not sure I see the value in "showing the team it's possible". I would presume the team are intelligent enough to be well aware that it's possible, given tradeoffs. And as it's clear those tradeoffs have been "traded" in this case, it doesn't seem like having the knowledge confirmed is particularly surprising.

The gp feels like less of a targeted individual criticism & more of a general musing about a trend.

Nobody is saying this author hasn't demonstrated discipline & won't maintain this project, but the statistical averages across most projects fitting this trend make it likely enough to question their worth in aggregate.

Agree on the timer.

In one sense I really enjoy the timer up to the point that I lose, but it feels very unsatisfactory, especially if I lose early, & I'm acutely aware the difficulty level it's set at will be experienced radically differently by different players (to the exclusion of most I would imagine).

Having a timerless mode is very much needed as an option - there's no real risk of "cheating" with these cookie-based browser games anyway since I could just have infinite retries in a private tab if I felt like doing that.

In fairness, both of these standards are from & for the cryptobro universe. Just that x402 is supported by large corps & l402 is created by some arbitrary shady crypto startup nobody has heard of.

It's even possible that x402 directly took ideas from l402 given l402 seems to be a few months older, but x402 has over 1000 contributions from almost 100 contributors & l402 seems to be solo project without any updates this year. It's not a moral preference, just a practical one.

Is L402 an open standard? It doesn't appear to be.

X402 is an open standard backed by the Linux Foundation.

I'm honestly not the biggest fan of the Linux Foundation as a company, nor of many of the names behind X402 (e.g. Coinbase) but if I had to choose between these two standards for something I was implementing, I know which one I'd be less worried about vendor lock-in with.

You seem to be arguing that government regulation, on its face, is default-good while the GP seems to be arguing that it is default-bad

The GP did indeed seem to be arguing it's default-bad (though I note you didn't go off at them for this). The reply has said nothing about it being default-good: only that it's not necessarily default-bad. You're assuming a black-and-white binary & by extension you're seeing arguments that weren't made.

There's nothing bad faith about the commenters post & assuming the role of a moderator in a discussion you're inventing phantom arguments in isn't doing you any favours.

I think this is likely a part of the friction for a lot of people - symlinks.

There's roughly two main ways to manage dotfiles:

- symlink

- copy & sync

The 2nd (what chez moi does) is pretty hard to get right from a UX perspective.

I must've tried to set up stow five or six times over the years, in between various hand rolled custom setups. I can't put my finger on why but I set up chez moi & it's been my setup since, much longer than any previous solution.

Chez moi is definitely not without its rough edges but it seems to have gotten the subtle essentials right enough for adhd me to not have abandoned it yet.

People succumbing to parental pressure become doctors.

A lot of folk go into teaching because there's high demand for workers & the academic path is relatively accessible.

You're probably mostly right about social workers, but it's a vague term & there's at least some categories of social worker that fill the same appeal as teaching.

Virtuosity is so hard to define, I'd say there's some virtue in almost every career direction but less in some than others. Certainly in my experience tech entrepreneurship has some of the lowest levels I've encountered.

Bill Gates' nerd image was as falsified as his philanthropic one. He was a shrewd businessman & knew PR well, that is all.

I don’t know why you’d think “being interested in nerdy stuff like computers” would somehow translate into virtuous behavior.

Because doing something you're genuinely interested is virtuous relative to doing something for personal/reputational gain or due to other social pressures.

some people got rich and powerful and their real personalities showed through

This could not be more deluded - the negative equivalent of the hustle culture myth: anyone can become a selfish asshole if they work hard enough. The idea that every person who's ever taken an academic interest in tech is just another William Gates III waiting to happen is a very weird way of looking at nerd culture.

On the contrary, this feels like a great (hypothetical) example of how to use coding agents effectively.

Codex as of right now would write some overpowered application that polls in a loop looking for Music App starts and killing them

Most human engineers would also do this. It's a relative rarity to find someone writing things this elegantly.

Similarly, if you asked an agent to "Stop the Apple Music app from launching", it would likely try to do what most humans would do. Otoh if you asked an agent to explain why the Apple Music app launches, based on the discoveries it presents to you from its investigation you would quickly discover for yourself that asking it to make a zero code app that collides with Music is the best course of action.

My sole input here is that software engineering has not protected itself as a field, and it will now pay the price for that.

& my point in raising that this is not an issue that's unique to software engineering is to argue that the demons you're proposing software engineers protect themselves from are distractions from the root cause. You're proposing software engineers need to protect themselves from something that's specific to their field when the problem is holistic.

Your initial post on class solidarity was extremely reasonable (even if I disagreed with it - see my comment above) but to follow it up with a post describing castes in a non-negative light is wild.

just to clarify:

1. my company also employs its fair share of folk that would fit into the so-called "idiot" category of my post - I just thought it was of note that I have encountered exceptions to this stereotype

2. I fully support what Ladybird is doing here & find it unfortunate that they have to. I didn't intend my post to criticise their move - my example is definitely the rare exception in a sea of unmaintainable garbage. I do think however that it was already a challenging prospect to manage garbage oss prs in the pre-llm era (see umpteen posts on maintainer burnout) & I wouldn't have faulted any open source project for doing what ladybird is doing even pre-llm.

Ooof. This is a big topic - I understand where you're coming from, but it's a common sentiment & one I've recently come to disagree more & more with.

Firstly: class solidarity. The apparent death of (or at least notable decline in) class solidarity is popularly lumped upon software engineers because they're relatively highly paid, but it's equally as absent in newly created positions (mainly within the IT sector) at all salary levels. There's been a concerted effort to erode class awareness in the private sector for the past 40+ years & it's been effective across all sectors, mostly in newly created job categories without pre-existing union culture. It's in no way specific to software engineering as a role nor to high salary positions.

Secondly: ai & llms. Currently these technologies are monopolised by corporate entities, with models generally being far too inefficient to democratise, so it's obviously tempting to conflate their very existence with their owners, but if you're singling out ai usage as some kind of affordance to the capitalist class you're missing the woods for the trees. You need to separate ownership from existence/usage.