At least this breakage is clear & obvious.
I did some testing of configuring Claude CLI sometime ago via .claude json config files - in particular I tested:
- defining MCP servers manually in config (instead of having the CLI auto add them)
- playing with various combinations of ’permissions` arrays
What I discovered was that Claude is not only vibe coded, but basic local logic around config reading seems to also work on the basis of "vibes".
- it seemed like different parts of the CLI codebase did or didn't adhere to the permissions arrays.
- at one point it told me it didn't have permission to read the .claude directory & as a result ran bash commands to search my entire filesystem looking for MCP server URLs for it to provide me with a list of available MCP servers
- when restricted to only be able to read from a working directory, at various points it told me I had denied it read permissions to that same working directory & also freely read from other directories on my system without prompting
- restricting webfetch permissions is extremely hit & miss (tested with Little Snitch in alert mode)
---
I have not reported any of the above as Github issues, nor do I intend to. I had a think about why I won't & it struck me that there's a funny dichotomy with AI tools:
1. all of the above are things the typical vibe coder stereotypes I've encountered simply do not really care deeply about
2. people that care about the above things are less likely to care enough about AI tools to commit their personal time to reporting & debugging these issues
There's bound to be exceptions to these stereotypes out there but I doubt there's sufficient numbers to make AI tooling good.
Those stereotypes look more like misconceptions (to put it charitably). Vibe coding doesn't mean one doesn't care about software working correctly, it only means not caring about how the code looks.
So unless you're also happy about not reporting bugs to project managers and people using low-code tools, I urge you to reconsider the basis for your perspective.
> it seemed like different parts of the CLI codebase did or didn't adhere to the permissions arrays.
I’ve noticed the same thing and it frustrates me almost every day.
I get the same feeling, but I think its not just the code agents.
All the AI websites feel extremely clunky and slow.
This is why I run claude inside a thin jail. If I need it to work on some code, I make a nullfs mount to it in there.
Because indeed, one of the first times i played around with claude, I asked it to make a change to my emacs config, which is in a non-standard location. It then wanted to search my entire home directory for it(it did ask permission though).
Not sure the comments are debating the semantics of vibe coding or confusing ourselves with generalizing anecdotal experiences (or both). So here's my two cents.
I use LLMs on a daily basis. With the rules/commands/skills in place the code generated works, the app is functional, and the business is happy it shipped today and not 6 months from now. Now, as as super senior SWE, I have learned through my professional experiences (now an expert?) to double check your work (and that of your team) to make sure the 'logical' flows are implemented to (my personal) standard of what quality software should 'look' like. I say personal standard since my colleagues have their own preferred standard, which we like to bikeshed during company time (a company standard is after all made of the aggregate agreed upon standards of the personal experiences of the experts in the room).
Today, from my own personal (expert) anecdotal experiences, ALL SOTA LLMs generate functional/working code. But the quality of the 'slop' varies on the model, prompts, tooling, rules, skills, and commands. Which boils down to "the tool is only as good as the dev that wields it". Assuming the right tool for the right job. Assuming you have the experiences to determine the right tool for the right job. Assuming you have taken the opportunities to experience multiple jobs to pair the right tool.
Which leads me to, "Vibe coding" was initially coined (IMO) to describe those without any 'expertise' producing working/functional code/apps using an LLM. Nowadays, it seems like vibe coding means ANYONE using LLMs to generate code, including the SWE experts (like myself of course). We've been chasing quality software pre-LLM, and now we adamantly yell and scream and kick and shout about quality software from the comment sections because of LLM. I'm beginning to think quality software is a mirage we all chase, and like all mirages its just a little bit further.
All roads that lead to 'shipping' are made with slop. Some roads have slop corners, slop holes, misspelled slop, slop nouns, slop verbs, slop flows and slop data. It's just with LLMs we build the roads to 'shipping' faster.
The permission thing is old and unresolved. Claude, at some points or stages? of vibe-coding, can be become able to execute commands that are in the Deny list (ie: rm) without any confirmation.
I highly suspect no one in claude is concerned or working on this.
I’d urge you to report it anyway. As someone that does use these tools I’m always on the lookout for other people pointing this type of stuff out. Like the .claude directory usage does irk me. Also the concise telegraphing on how some of the bash commands work bug me. Like why can it run some commands without asking me? I know why, I’ve seen the code, but that crap should be clearer in the UI. The first time it executed a bash command without asking me I was confused and somewhat livid because it defied my expectations. I actually read the crap it puts out because it couldn’t code its way out of a paper bag without supervision.
No matter what which stereotypes you think the developers adhere to, your should file the bugs. Or stop complaining about them.
Sounds like a malware
Good info. Now I understand why they refused to acknowledge the UX issue behind my bug report: https://github.com/anthropics/claude-code/issues/7988
---
(that it's a big pile of spaghetti that can't be improved without breaking uncountable dependencies)