Join Nostr
2026-04-05 08:46:41 UTC
in reply to

jonny (nonvenomous) on Nostr: But wait! we can produce some bash script at ~/.claude/statusline.sh, but we were ...

But wait! we can produce some bash script at ~/.claude/statusline.sh, but we were also given permission to read the user's ~/** and told to read the PS1 in their local configuration! how does this work again? what is going on? How is the statusline actually invoked by the program?

it turns out that all that stuff about PS1, and the entire need to access our local configuration is totally irrelevant! instead we have *another* incoherent call chain to actually invoke it - the TUI builds the input args, calls executeStatusLineCommand, which then routes into some execCommandHook function which is 600 lines long and handles ... uhhh.. wait no it just handles the status line command and one other thing... and uh... fuck the entire hooks system is ah... there isn't really a concept of a 'command-based hook' except for in this one context so... , well.... ok let's just say it goes into one of hundreds of "execute something" functions.

So what happens is that even though the whole TUI is an execution environment that behaves like a shell and controls all string rendering, it then invokes your system shell to run your statusline bash script and return a string. *even that* is too simple by half - there's actually a whole command wrapping system and the ability to execute **further agents** off the results of stdout

See what i'm saying about the yarnball of bullshit being impossible to stop unraveling once you start pulling at any single thing?