u/CatTwoYes

Hi,

I know this sub is generally (and rightfully) exhausted by the endless wave of "AI wrappers" that try to take over your entire system, force you into clunky web UIs, or dump massive global configs in your home directory.

I felt the same way. I wanted to use LLMs for daily dev tasks, but I didn't want a heavy "co-pilot". I wanted a standard, dumb pipe that I could chain with grep, awk, and jq.

So I built Huko.

It’s an open-source CLI tool designed strictly around the Unix philosophy: do one thing, take stdin, and spit out stdout (or JSON).

Here is what makes it fit for a proper Linux environment:

Pipes all the way down: It just reads and writes text. You can drop it into any bash script. cat /var/log/syslog | grep "error" | huko -m -- "summarize the root cause" > report.txt
State isolation via .huko/: Context bleed is terrible. Instead of a global daemon, Huko scopes its memory and sessions to the current working directory using a hidden .huko/ folder (exactly like how .git/ works). You cd in, it remembers the project context. You cd out, it's a clean slate.
Controlling the blast radius: Giving an LLM access to bash is a security nightmare. Huko has built-in regex gating (huko safety deny bash 're:^rm -rf'), scrubs secrets before they leave your machine, and can execute destructive commands inside an isolated Docker container (huko docker run).
Two Gears (Lean vs. Full) & Algorithmic Compression:
- Lean Mode: For quick, one-off pipeline filtering, it runs with a tiny ~400 token overhead. Zero ceremony.
- Full Mode: For complex, multi-step execution, it brings in robust task planning and full tool orchestration. To prevent massive context bloat during long sessions, it uses a pure-algorithmic compression strategy (inspired by Manus) to prune the context tree locally. No slow, expensive LLM summarization loops—just fast, zero-overhead algorithmic pruning.
- Proof of concept: Full mode's planning is solid enough that a significant portion of Huko's own codebase was actually written, debugged, and refactored by Huko itself.

The Reality Check (Why I'm posting here):

Huko is a brand-new release (v0.x).

Even though it successfully bootstrapped part of its own codebase, let's be real: running in my solitary environment is different from surviving the wild. It has rough edges, the architecture might have blind spots I haven't considered, and there are almost certainly edge cases in local file handling or standard I/O streams that will break it.

I'm posting here because I want raw, unfiltered feedback from Linux power users.

Does this approach to state management actually make sense to you?
Are there glaring security holes in how I handle regex gating?
Tear the architecture apart.

If this sounds mildly useful, I’d be honored if you tried to break it. Contributions, issues, or just telling me why this is a terrible idea are all highly welcomed.

Repo: https://github.com/alexzhaosheng/huko
Site: https://huko.dev (It’s just NPM install and go).

Thanks for your time.

[OC] I was tired of AI tools breaking my terminal workflow, so I built a pipe-friendly CLI that acts like a standard Unix filter (with .git-like state isolation). It's brand new and I need your harsh feedback.