Lots of praise for Pi in this thread, so I'll offer up a diverging opinion. Given all the hype, I was a bit underwhelmed by Pi. It definitely has some good ideas around customization, but it annoyed me in many little ways.
For a program that's minimal it sure takes a long time to start up, the standard C-p and C-n bindings don't work, it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME directory.
I think there's still space for another harness that's 1/ open-source, 2/ written in a fast compiled language (Rust, Go, etc.) and scriptable in a simple (aka non-JS) scripting language (Lua, etc.), 3/ less opinionated and more sensible so things like XDG isn't a WONTFIX.
But I agree with you, it's biggest weakness is that for a real long time the tagline of it was "there are many harnesses, this one is MINE" (That being Mario's)
I have a lot of respect for Mario and his team, but there's things like you've pointed out that deviate from standards, and other issues that I've seen get posted, only to get knocked down by the team as WON'T FIX because, even though the new owners changed the tagline from MINE to YOURS... It's still very much Mario's.
I do like opinionated things. Truly. But I'm also of the opinion that standards exist for a reason.
That said. I like Pi so much that it's my daily driver, and I've created an ecosystem of plugins to do everything I want, having them all tie together and communicate through the shared bus. Pi is really a good harness.
It's just, well. I don't agree with some of the opinions.
If I'm going to add another thing here... Whilst you cannot get everything you need from the openAI API spec, you can get a surprising amount to get a model config. That said. Versions of Pi are still shipping with model configs for certain inference providers. I do hope that gets decoupled at some stage. I see the groundwork being laid.
So the work is being done in the right direction. I applaud the team but I do get the feeling that a lot of this is because people want to contribute, but the team really wants to hand craft this. And that's great
Ignoring the military stuff, I feel like it is saying that this harness, although stamped from a mass produced part, is mine once I take possession of it. An extension of me?
My read sees pi as a starter kit. It's job is to build personal workflows and not to dictate a workflow. Copy on the site calls it minimal and tells us to 'adapt pi to your workflow, not the other way around.' In other words a fleshed out pi is unique to you.
> For a program that's minimal it sure takes a long time to start up, the standard C-p and C-n bindings don't work, it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME directory.
This drives me mad, I believe Ollama and Claude Code also do this. Seems to be rife in the LLM world. IMO there's no excuse for new software sticking dotfiles in my homedir in 2026.
In my experience, the Rust community very much cares - it is a struggle to find a modern Rust application of any popularity that does not abide by XDG.
.cargo's placement is a historical mistake that can't be undone now, but ecosystem participants are generally good participants.
Not sure about use in the Go community at large but Go introduced os.UserConfigDir[1] which is portable across Windows, macOS, Plan 9 and Linux/BSD as per XDG back in 2019. Also CacheDir.
Ghostty has chosen to use that as the default and I feel like it's going to be the tipping point where people will assume $HOME/Library/Application Support is normal for CLI programs.
fwiw, it absolutely drives me nuts that cli programs are putting configs in that hard to reach folder (long path name and _spaces_ in the folder name ugh)
> IMO there's no excuse for new software sticking dotfiles in my homedir in 2026.
Agreed, and also, tinfoil hat time:
I believe they opt for this so that state and config files don’t need to be distinguished (it all goes into ~/.appname the same). It’s still not an excuse, but maybe laziness is the reason?
I'd also add that convenient recursive folder creation was only added relatively recent for many languages (eg: "std::filesystem::create_directories" was only added in C++17). And since "~/" is pretty much guaranteed to exist, the fewer folders you needed to create, the less code you had to write.
I think underuse/under-marketing of XDG_STATE_HOME is a contributing factor. Developers see XDG_DATA_HOME and XDG_CONFIG_HOME and, following the spec, don't feel like their app's files conform to either definition. It's easier to just not bother. Neovim now uses all 3 and it's very nice IMO.
The problem with the XDG spec is that it now forces you to have different paths on different platforms. It just increases the complexity and at the end of the day unless all software adheres to it, you still end up with a “polluted HOME”.
I’m not a fan of config directories being in different locations on different platforms because it’s now one extra thing everyone needs to handle.
(Disclaimer: I work on Pi but I dislike XDG in all settings)
Platform standards already require things to be in different locations compared to *NIX dotfiles and dotdirectories - for example Windows %APPDATA%.
I find it a bit shocking that someone working on an agent harness can't be bothered to spend 5 minutes to research this with the help of an LLM and holds such rigid and uninformed views.
And if you don't want to respect platform standards, just respect XDG on all platforms. The .app solution is the laziest one possible.
Just follow XDG everywhere and create .config/app & co everywhere, at least that way there's a chance more apps end up in subfolders instead of ending up with a million folders in the user directory on BOTH Linux and non-Linux.
I suspect some people are out there who actually like the single directory style. Obviously it's easier for the software developer, but I suspect some users like it too because everything's all in one place. It's very likely that Mario is one of those people.
I will say that even though I really don't like having a cluttered home folder, I do appreciate things being more or less in one place and so can be easily uninstalled and cleaned up. Flatsweep even being a thing is a testament to the tedium created by dispersing everything across the file system. It reminds me of macOS and not in a good way: I had an equivalent to Flatsweep on my old macbook but I couldn't remember its name so I searched "macos app cleanup tool", and the first page is just a bunch of comparison articles for the 10 (or whatever) best cleanup tools. This shouldn't be a thing. Alas, it is because applications can't or wont clean up after themselves.
Totally valid, and the Unix-style filesystem sprawl is definitely a pain sometimes. On the other hand, when an application does follow standards, you always know where something is, and just by looking at the name of the directory you know what's in there.
The other thing that's nice about the XDG standard is that it generally encourages developers to split binary state data, configuration, etc. even if you do it all within one folder, that's better (for the user) than jumbling it altogether in one big SQLite database or whatever.
It is a note that a lot of applications and even package managers are kind of moving back to the model you describe. For example Homebrew installs each package into its own prefix and symlinks into /opt/homebrew/bin,lib,etc...
I still don't like hard coding the MYAPP_HOME dir in ~/.myapp and prefer an environment variable to configure it. Personally I put all such folders into ~/.local/opt/$MYAPP if possible.
Written in C, tiny footprint, minimalist approach to system prompt and tools (yet essential batteries are included, for example - it has subagents with presets, and background bash tasks out of the box), high quality polished presentation, inspectable (usable transcript view), does not mess with terminal scrollback, respects XDG directory spec, etc.
Open source, MIT-licensed, no commercial agenda. A tool that I myself wanted, so I built it.
It starts up for me in under a second on my M4 mac. (Obviously could be faster, but doesn't bother me personally on my hardware)
My one main "issue" is with using the pi-sandbox extension. It's based on a forked claude code sandbox runtime. Not exactly sure why a fork was needed, and the fork is a bit behind now. I also wish the sandbox feature worked a bit more like how Cursor's sandboxing worked. Not familiar with Claude Code sandboxing, so can't compare that. I describe the issue and a (slightly hacky, but productive enough) workaround here: https://github.com/carderne/pi-sandbox/issues/50
Obviously the fact that I can fork a plugin for pi and customize it as needed is quite a plus too. Really all the other features work quite well for me!
I don't get the XDG appeal of having all the data of an app scattered all over the home dir when I can just have a .dir of an app with everything inside.
Backups. If a program properly follows the spec I can just `rsync ~/.config/foo` or store it in a repo and not have to worry about it. If a program doesn't follow the spec I now have to write program specific filters for rsync/custom .gitignore entries to avoid backing up state and cache. Now multiply that across dozens of programs written by lazy devs who don't want to write 12 lines of code to determine the correct location for their files.
This exactly. My rsync patterns file is littered with dozens of edge cases to capture the configs and ignore state/caches of stuff that doesn't follow XDG. Really dislike the chore of double checking everything and adding new stuff to the list every time I take a backup.
Even worse are those that seemingly follow XDG but not really, like a lot of Electron apps, that just shove config, state and cache in ~/.config.... sigh
> I think there's still space for another harness that's 1/ open-source, 2/ written in a fast compiled language (Rust, Go, etc.) and scriptable in a simple (aka non-JS) scripting language (Lua, etc.), 3/ less opinionated and more sensible so things like XDG isn't a WONTFIX.
Written in Go, compiled binary, respects XDG (e.g. uses ~/.config/crush to store config), etc. No Lua scripting, but it includes a skill to manage its own configuration.
The minimal harness is the one you build yourself. Use pi to do it if you want. Getting something barebones takes less than an hour. Then you can extend it exactly how you want.
Here's some annoyances of my own that honestly baffle me:
- The command to exit the program is /quit, not /exit like literally everything else. If you type /exit, it'll get sent as a message to the AI. Apparently, /exit was an alias of /quit at some point, but was removed because it was simply too intuitive.
- It has terminal subcommands, such as `pi install` to install an extension. Any reasonable person would expect that `pi help` would give you a list of such commands. Nope! That actually starts it up and sends the message "help" to the AI. Amazing.
It's a common theme that most AI-generated or AI-adjacent software is full of nonsensical little decisions like this, that almost make it feel like it's not intended to be used by sane humans.
The fact that you can easily change the key bindings and $HOME and tons of other stuff by telling pi itself to go write an extension in 20 seconds(or just go customize one after forking it) is awesome, not because you can do it YOLO but because I could on-board faster with these and get to work ASAP.
I've been able to get near exactly the workflow I want: Navigate and search sessions, Delegated extensions that allow you to run deterministic code for sensitive operations like read, write and search-result inference, I have an extension to prune tool calls in batch mode: saves tons of context space on GPT-5.x trading off prompt prefix performance. And another one very similar to auto search mentioned in the blog. And the Tmux integration allows you to spin work trees in separate windows/panes.
I've never had a perf issue simply because harness interaction being a human in the loop process you(thinking and writing) are the bottleneck.
I personally also don't like this, so use cargo to install it, it's in the readme. Takes a reasonable time to build on my X220, but on a modern computer it is plenty fast.
Is there a meaningful security difference between curl-pipe-bash and cargo install --git? Couldn't the cargo install include a buildscript that jumps right into a shell?
Sure, but you can review the git repo's content/commits in plain text, while curl-pipe-bash would require you to reverse engineer the binary that's downloaded.
If somebody hacks the project's home page and switches the download location to a hacked binary, you'd be none the wiser. Of course, somebody could hack the repo and add a deliberate vulnerability as well, but at least you would have a trail of it.
Me too, maki in --yolo mode within an incus NixOS container, giving maki rootless (nested) podman and nix flakes powers (so it can install and run whatever tools it needs), with 100% ds4-flash it's extremely powerful and super cheap.
I'm building roughly this in Rust: single binary, XDG-native, with Landlock/seccomp, scoped filesystem access, default-deny egress, and policy-based approvals. https://github.com/vinhnx/VTCode
I'll take any scripting language over Lua any day. Every time I had to extend a tool that used Lua as a scripting language, I abandoned that tool because Lua was such a pain. I genuinely don't understand the praise it gets
I'd agree with you based on the language itself; Lua has some annoying idiosyncrasies like e.g. (my main pet peeve) 1-based indexing.
But I suspect the positive opinion on Lua stem more from the standardized environment the language is built around (i.e. how it is embedded into applications): If you don't explicitly pass capabilities like file handling etc. into the script, it CANNOT use them. Sooo many scripting languages get this wrong, it's actually embarassing.
1-based indexing is really a lame duck argument - if you can't get past that, you're simply being stubborn.
You absolutely can have tables indexed at 0 - what you cannot do, is fail to take responsibility for the use-patterns you apply to those tables, if you do so - and more specifically you have to take responsibility for the requirement that you use 0-based tables, instead of more optimal methods.
The table is an extraordinarily flexible type. You will gain immensely from using it properly - whether its the newbie dilemma over pairs()/ipairs(), or whether its the professional metatable manipulations - the power of this type is undeniable.
However, if you cannot get past the fact that you must learn it, and that it is applicable to your requirements in every single case, then you are for sure going to have a hard time.
Too much power + too little attention to important details = burnt fingers = endless whining. This is my personal stance having used Lua for decades now, professionally and personally, to do amazing things.
I have used Lua for years and love it, I don't have any issues with its features, and I've shipped many products with it, across a variety of use cases.
I genuinely understand however, that some people just don't get Lua, and have little energy for it.
However, I think it is awesome and every good software developer should have some experience with it. Whether it is a positive or negative one, you will learn a lot that will help you stay relevant in today's crazy software world.
I have similar sentiment but still haven't spent time to give it due process to come to good conclusion.
I tried the bare pi and now I am using oh my pi. At this point I feel that unless I am really concerned with maximizing token usage the Claude, Codex and Cursor cli are good enough. I think if you're looking for a reason to use pi versus you have a problem and pi is the solution than it's probably not a good fit.
I do think using it with open weight models may be worthwhile. I can see value with using it with a open router subscription. I have used opencode but I would rather standardize on it pi.
I've absolutely had the same experience. Pi has been praised a lot, people speaking so highly of it's code quality.
And then I installed it and found all the problems you mention. Not only that but I read Github Issues about the XDG problem and was a bit taken aback by the reaction of the developer.
It's one of the best agents I have used so far but I'm still looking for a very lightweight, token efficient agent NOT written in a JS framework and which respects XDG
C-p and C-n (aka Ctrl-P and Ctrl-N) are the Emacs-style keybindings for previous (line) and next (line), very commonly encountered on the command line and in terminal applications. For example, most shells can use this in addition to up-arrow and down-arrow to cycle thru command history. Many, many more examples exist of applications (not just terminal-based, there are plenty of GUI apps too) that use this convention, as well as other Emacs-style keybindings (e.g. C-a for beginning of line, C-e for end of line).
but also highly opinionated (no mcps, no agents.md, no system prompt, …)
so not sure it checks all of your boxes
that said: because smol is so smol you can adapt it easily and agents (including smol) can work well with it because the whole implementation fits comfortabliy into the context window
It's not 20 lines of Go because you decided to merge multiple lines of code into one. Why not advertise it as one line of code if you don't care about readability?
Edit: after reading my fork of smol, I realized it literally just feeds everything into bash, making it completely pointless.
Edit 2: I decided to read the readme instead and it raised a question
"Compare smol with Pi, OpenCode, Codex, Hermes, Claude Code and highlight key pros and cons. Audit the code of all of them and tell me how confident you are that you found all potential issues of smol vs the other agent implementations?"
After thinking about the difference between the original and my fork, I'm confident that smol has more problems than all of the agent harnesses combined and my fork has made an important step towards fixing one of those issues.
Edit 3: I hope the community can fork my version and add sensible variable names.
Edit 4: I can't decide whether this is the best satire of coding agents I've ever seen and I just ruined it or it is horrifying that someone even entertains the idea of publishing it.
I mean, you can't be serious, right? Think about the unintentional commentary you're making here.
You're saying it can be understood in an afternoon but it is intentionally obfuscated.
It might as well be proprietary code, but if it is proprietary code, you're actually making fun of all the coding agents for being a walking security nightmare, because in the end all they do is run bash and no amount of sandboxing or regexes will make bash secure.
So why not drop the pretenses and just expose the coding harnesses for what they are? Inscrutable bash executors that have the potential to go out of control.
your favorite agent will help you de-golf and analyze the implementation
I'm confident you can understand what it does (and does not do) and why in an afternoon
(probably in 20-30 minutes actually, even if you are not familiar with Go)
the same is way more difficult with larger agent implementations even if you only want to understand the direct implementation ignoring all the 3rd party dependencies that come with them
i guess what i'm saying is: it's not so hard to start with a minimal, well working agent and then only add exactly what you need instead of taking a more complex agent and then trimming it down or configuring it (and staying compatible with its continued development and deps)
pi is in YOLO mode by default. What the heck do you care if it's respecting XDG or not: this thing is not meant to be run in your main user directory with access to your secrets, bank accounts, emails, etc.
I couldn't care less about something that's meant to be run/discarded/re-created in a VM (or microVM or container) at will respecting XDG or not.
> For a program that's minimal it sure takes a long time to start up
It took the same amount of time (3 seconds) as cursor-agent and codex on my machine, which isn't particularly high-spec.
> the standard C-p and C-n bindings don't work
It has programmable keybindings and you can ask the agent to remap them in five minutes, if not 30 seconds.
> it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME directory
You can make it put .pi/agent anywhere with $PI_CODING_AGENT_DIR in 10 seconds.
> scriptable in a simple (aka non-JS) scripting language
This doesn't make any sense. The very point of Pi is that instead of implementing all of your features directly in the harness, you make the harness minimal and then implement the functionality you want as extensions, which necessarily means that you have some powerful and expressive extension language, ideally the one the harness was written in.
I suspect that if the harness was written in Lua (which I love and is probably the least bad choice of "scripting" language), you would have far more issues with it.
If these are your complaints, then this is one of the strongest endorsements of Pi that I've ever seen. I think I'm bookmarking this comment.
A contrarian is "A person who likes or tends to express a contradicting viewpoint, especially from one held by a majority of people, usually because of nonconformity or spite."
The post I replied to is literally being contrarian:
> Lots of praise for Pi in this thread, so I'll offer up a diverging opinion.
Meanwhile, my post was not being contrarian in the slightest. I didn't offer a contradictory viewpoint - I provided factual information and context to dispel false claims/misinformation in the post I was responding to (e.g. the claim "the standard C-p and C-n bindings don't work" is highly misleading/false because you can trivially rebind them), and the opinions I provided were completely orthogonal to the opinion expressed ("I suspect that if the harness was written in Lua [...] you would have far more issues with it."
I expressed no opinion either for or against "Given all the hype, I was a bit underwhelmed by Pi. It definitely has some good ideas around customization, but it annoyed me in many little ways."
It always surprises me when someone so confidently makes an objectively incorrect statement when they could have spent 30 seconds looking up the definition of a word and realized that they were in the wrong.
> Being contrarian for the sake of it is not good form.
Why would you say that? Is it good form to post that someone is being contrarian for the sake of it? OP’s comment looks like constructive criticism with plenty of good points.
> It took the same amount of time (3.5 seconds) as cursor-agent and codex on my machine.
So what? Nobody is pretending that these are minimalist. Codex is 1.2M of Rust LOC.
> which necessarily means that you have some powerful and expressive extension language, ideally the one the harness was written in.
Don’t be silly, JS is a joke. I was going to check Pi out, but now that I know it’s based on a shitty stack, I’m staying the fuck away from it. I don’t have the RAM to spare.
> If these are your complaints, then this is one of the strongest endorsements of Pi that I've ever seen. I think I'm bookmarking this comment.
>> Being contrarian for the sake of it is not good form.
> Why would you say that?
Because it's true.
> Is it good form to post that someone is being contrarian for the sake of it?
It's orthogonal to good form - it's preserving the value of HN, which is meant for intellectual curiosity and not knee-jerk emotional reactions, like your comment.
> OP’s comment looks like constructive criticism with plenty of good points.
You must have missed the very first line in their comment where they said:
> Lots of praise for Pi in this thread, so I'll offer up a diverging opinion.
...which is literally admitting to being reflexively contrarian.
Additionally, their criticisms were extremely shallow and/or misleading, and I addressed every one.
> So what?
Nobody is inconvenienced by a 3.5s startup time of an application meant to run for hours or days. That's a trivial complaint akin to arguing about the color of paint on a bikeshed.
> Don’t be silly, JS is a joke. I was going to check Pi out, but now that I know it’s based on a shitty stack, I’m staying the fuck away from it. I don’t have the RAM to spare.
You're just operating based on emotion and not a state of reason or intellectual curiosity. And I highly doubt that you "were going to check Pi out" - this wording follows the pattern of fabricating falsehoods out rage due to an opinion expressed that you didn't like.
>> If these are your complaints, then this is one of the strongest endorsements of Pi that I've ever seen. I think I'm bookmarking this comment.
> For the record, I measure acceptable latency in milliseconds. I think it has something to do with my brain.
That's a personal preference thing. You're not really being inconvenienced.
> They’re very clearly stating that they’re expressing their opinion because it is underrepresented.
That's literally the dictionary definition of being contrarian:
"A person who likes or tends to express a contradicting viewpoint, especially from one held by a majority of people, usually because of nonconformity or spite."
I suggest consulting the dictionary before using terms you're not familiar with.
> No.
If you're going to copy-paste random pieces of text without making a point, you probably shouldn't be on HN. HN is for intellectual curiosity and debate, not Reddit-esque expressions of randomness conflated wuth humor.
- I regularly have 10+ instances of my harness running or idling on my laptop.
- My laptop is often at near-100% CPU and memory usage due to the (irreducible) cost of the development tools and environment.
- I often (50% of the time) downclock my laptop’s CPU to 1-2 GHz to save battery and/or reduce noise and thermals while charging.
- I sometimes run my harness on machines that are low-power, low-RAM single-board computers.
If my harness was written in JS, this would be both annoying in terms of responsiveness and limiting in terms of how much work I can do in parallel. This is why using JS for serious software is a... subpar decision.
> but then it also means you can't use Claude Code because it also runs on top of JS.
That's fair. I think with a lot of these harnesses they didn't really think people would be running so many instances of them at once
I think for claude code it really would be best if they made it native, but for plugins I think JS wins, because it's just a lot more easier for most to write plugins in that.
from my POV the performance used to be bad but it's pretty good now, every now and then though it'll start just growing in memory usage and needs to be restarted every now and then. so if you'd 10x that then I could see it really limiting workflows, especially with SBCs
The claims being made here are fallacious in three extremely basic ways.
First, "I regularly have 10+ instances of my harness running or idling on my laptop" implicitly asserts that you need that many instances running at once.
You don't. You can have a single instance running that handles your sessions in parallel.
Second, "I sometimes run my harness on machines that are low-power, low-RAM single-board computers." presumes the whole agent has to run on the SBC itself. It doesn't. There are agents (including Pi, which makes this even sillier) that can run their tool calls in a separate process/host, meaning that the agent can live on your development machine while the tiny tool-call daemon runs on the SBC.
Finally, "If my harness was written in JS, this would be both annoying in terms of responsiveness and limiting in terms of how much work I can do in parallel." could only be written out of a complete lack of understanding about how harnesses are actually implemented.
Agent harnesses don't do very much. The limiting factor is not the harness itself, but in the filesystem (reads, writes, file searches, greps), the computational tool calls (compilers, linters, evaluating the program), and the LLM API itself.
Your arguments against Javascript appear to be based on fallacies, lack of understanding of technology, and strong emotions against JS rather than actual fact.
This is getting silly, I can’t tell whether you are kidding, never launched a Node-based app, or never checked htop.
> that can run their tool calls in a separate process/host
That indeed seems like a simple and elegant setup. I can’t recall a single instance of using a harness when I didn’t want the tool calls to be local, though. Why would I be SSHing into a SBC just to run the agent back on my laptop?
> You can have a single instance running that handles your sessions in parallel.
Sounds even more elegant! Presumably, they communicate via HTTP?
> implicitly asserts that you need that many instances running at once.
I don’t need to, but I can. That’s the entire point, in case you’re still missing it.
> Your arguments against Javascript appear to be based on fallacies, lack of understanding of technology, and strong emotions against JS rather than actual fact.
> This is getting silly, I can’t tell whether you are kidding, never launched a Node-based app, or never checked htop.
You're very much operating based on emotion rather than reason. That's fine in general, but it's not OK for HN, which is not a place to blast out your emotions and try to assert that your opinion is factually true by getting maximally angry about it.
> That indeed seems like a simple and elegant setup. I can’t recall a single instance of using a harness when I didn’t want the tool calls to be local, though. Why would I be SSHing into a SBC just to run the agent back on my laptop?
You don't understand how harnesses work. Let me explain: in a harness, the tools that the harness provides are the only way for the agent to interact with its environment, and as such, if the harness is run on one host, and the tools on another, the agent's perspective is that it is running on the second host. This is effectively true modulo some small set of scenarios that are mostly irrelevant in the case of "I'm SSHing into an SBC" (e.g. the harness logic and LLM API calls would both be happening on the SBC, which you definitely don't want when you're resource-constrained).
> Sounds even more elegant! Presumably, they communicate via HTTP?
No. Why would you think that? Again, I don't think you understand how harnesses work.
> I don’t need to, but I can. That’s the entire point, in case you’re still missing it.
That's a useless point, if so, akin to saying "I want to have Vim running at address 0x00000001beef0000 in physical memory" - you're conflating use-case (needing a large number of agents running in parallel so you can work on things in parallel) with implementation detail (having a large number of separate processes running on your computer).
> How beautifully ironic.
I'm meeting every single one of your technical arguments and factual inaccuracies (e.g. your misunderstanding of the word "contrarian"), and you're continuing to get very angry at Javascript. I don't think there's any irony here.
For a program that's minimal it sure takes a long time to start up, the standard C-p and C-n bindings don't work, it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME directory.
I think there's still space for another harness that's 1/ open-source, 2/ written in a fast compiled language (Rust, Go, etc.) and scriptable in a simple (aka non-JS) scripting language (Lua, etc.), 3/ less opinionated and more sensible so things like XDG isn't a WONTFIX.