IDK man it feels like you are making a less-useful unsafe wheel.

- file types exist for a reason

- this is just prompt engineering which is already easy to do

I agree that script execution safety is a real concern, as it is with AI coding tools generally. By default the runnable markdown files do not have permission to execute code, unless you specifically add those permissions.

I can see there might be valid arguments for enforcing file type associations for execution at the OS level. These are just text files, and Unix-like environments support making text files executable with a shebang as a universal convention.

I am a fan of that unix-like philosophy generally: tools that try to do a single thing well, can be chained together, and allow users to flexibly create automations using plain text. So I tried to stick with that approach for these scripts.

I'm a bear of little brain, and prompt engineering makes my head hurt. So part of the motivation was to be able to save prompts and collections of prompts once I've got them working, and then execute on demand. I think the high readability of markdown as scripts is helpful for creating assets that can be saved, shared and re-used, as they are self-documenting.

As far as I understand, by default your claude-shebang files inherit the permissions that have been previously granted in the current directory you're executing them in.

The ability to execute code is not granted as part of the directory permissions. By default the scripts will not be able to execute code, only run analysis and text gen tasks. You need to explicitly add the flags for permissions to execute code. There is an example of this above and a few more in the repo README.

Why wouldn't Claude Code, called by you, do its normal .claude/settings.local.json processing?

The constraints work consistent with Claude’s -p mode. It is isolated from your regular Claude interactive sessions and settings on purpose. And that makes it safer by default because you have to explicitly add permissions.

You can try this out and you’ll see what I mean if you run a few simple examples. This approach was based on experimentation and trying to be consistent with Claude’s own philosophy here.

Ah so -p doesn't follow the local settings. TIL.

I've tried Go scripting but would still still prefer python (uv is a game changer tbh). My go-to for automation will always be powershell (on linux) though. It's too bad PowerShell has the MSFT ick keeping people away from adopting it for automation. I can convince you to give it a try if you let me

Anyone who has had the pleasure of being forced to migrate to their new Fabric product can tell you why sales are low. It's terrible not just because it's a rushed buggy pile of garbage they want people to Alpha test on users but because of the "AI First" design they are forcing into it. They hide so much of what's happening in the background it is hard to feel like you can trust any of it. Like agentic "thinking" models with zero way to look into what it did to get to the conclusion.

Every new Microsoft product is like this. It all has that janky, slapped together at the last minute feeling.

I can see why Microsoft likes AI and thinks it's great for writing code.

The kind of code AI writes is the kind of code Microsoft has always written.

It's so bizarre because their devs tools and frameworks are so well thought out. You'd think if they're using those it should come out not janky. But I don't think they do use their own devs tools, and I also don't think it would help.

They don’t use their own tools. It’s react, electron, JavaScript and Python. And I strongly suspect by Indian engineers from the recent learn page write ups

using what fab? lol

Windows 10 will be the last msft os I ever use. I rebuilt using AMD CPU/GP booted up Fedora 42 and I have never had to run a single shell command to get anything to work. I don't even notice my OS. Work, games, local models (this one still takes some tweaking but is better), all work fine

LLMs by definition do not make facts. You will never be able to eliminate hallucinations. It's practically impossible.

Big tech created a problem for themselves by allowing people to believe the things their products generate using LLMs are facts.

We are only reaching the obvious conclusion of where this leads.

A talk I went to made the point that LLMs don't sometimes hallucinate. They always hallucinate -- its what they're made to do. Usually those hallucinations align with reality in some way, but sometimes they don't.

I always thought that was a correct and useful observation.

To be sure, a lot of this can be blamed on using AI studio to ask a small model a factual question. It's the raw LLM output of a highly compressed model, it's not meant to be everyday user facing like the default Gemini models, and doesn't have the same web search and fact checking behind the scenes.

On the other hand, training a small model to hallucinate less would be a significant development. Perhaps with post-training fine-tuning, after getting a sense of what depth of factual knowledge the model has actually absorbed, adding a chunk of training samples with a question that goes beyond the model's fact knowledge limitations, and the model responding "Sorry, I'm a small language model and that question is out of my depth." I know we all hate refusals but surely there's room to improve them.

All of these techniques just push the problems around so far. And anything short of 100% accurate is a 100% failure in any single problematic instance.