Coder Legion - Recent posts tagged cli

Terminal Agent vs. Web Chat: Pick by Blast Radius

Thu, 22 Oct 2026 11:19:20 +0000

Every major AI lab now ships a command-line agent that runs on your machine with access to your files and shell. The deciding factor is which tasks you deliberately keep out of it. The deciding factor is simpler than most teams make it.

The Idea: Scope the Damage, Not the Capability

The better question when evaluating a terminal agent is blast radius: if this thing does exactly the wrong thing, what does it touch and how fast can you undo it? A web chat window has a blast radius of zero - the worst outcome is bad text you paste somewhere. A CLI agent with write access to a git repo has a blast radius of "whatever's uncommitted." The same agent with your production credentials in its environment has a blast radius of your business.

Blast radius is a property of the task, not the model. You can decide it in a planning meeting before anyone writes code. Refactoring tests in a throwaway branch? Low radius, high tolerance for a wrong turn - let the agent run. Editing an infrastructure config that deploys on merge? Same model, same prompt quality, completely different decision.

Real Example: Three Tiers, One Flag

A practical setup most CLI agents support in some form - approval modes plus a sandbox:

# Tier 1 - scratch work: let it run, git is the undo button
agent --mode auto-edit --cwd ~/experiments/parser-rewrite

# Tier 2 - real repo: propose diffs, human approves each write
agent --mode suggest --cwd ~/work/billing-service

# Tier 3 - anything with live credentials: read-only, no shell
agent --mode read-only --no-exec

The rule that makes this work isn't the flag - it's what decides the tier. Three questions, in order:

Is it reversible in under five minutes? Committed git history, yes. A sent email or a dropped table, no.
Does the environment hold live secrets? If the agent inherits your shell, it inherits your API keys. Check what's actually exported.
Would a wrong answer be obvious? Broken tests fail loudly. A subtly wrong SQL filter in a revenue report does not.

Two "no" answers and the task doesn't belong in an autonomous loop yet - regardless of how good the model is.

Key Takeaways

Judge AI agent tasks by blast radius (what breaks, how fast you recover) rather than by model capability, which changes too often to plan around.
Reversibility, credential exposure, and error visibility are three checks any PM or engineer can apply before a single line of config is written.
Approval modes and sandboxing aren't friction to work around - they're how you move fast on the low-radius 80% of work without betting the other 20%.

Which tasks have you already moved into an auto-approve loop - and what was the one that made you move it back out?

Sources referenced: Hacker News discussion on OpenAI CLI

I Built a C++ CLI That Hunts Down Secrets Hiding in Your Git History

Wed, 14 Oct 2026 22:57:01 +0000

We've all done it. You commit a .env file by accident, catch it a few commits later, delete it, and breathe a sigh of relief. Except... it's not gone. It's still sitting in your Git history, one git log -p away from anyone who clones the repo.

That's the problem GitHub Secrets Watcher is built to catch.

What it does

GitHub Secrets Watcher is a command-line tool written in modern C++20 that scans your GitHub repositories - public or private (with a token) - and walks back through commit history looking for accidentally committed environment and config files: .env, config.js, and similar patterns that often carry API keys, database credentials, or other secrets.

For every hit, it gives you a direct link to the exact commit where the file appears, so you're not stuck digging through history manually to remediate it.

Importantly, it's strictly read-only. It never modifies, deletes, or rewrites anything in your repositories - it just reports what it finds so you can decide what to do next (rotate the secret, scrub the history, etc.).

Key features

Scans all repos for a given GitHub username, public by default, private too if you pass a token
Walks a configurable depth of commit history across branches
Skips noisy directories like node_modules, .git, and dist
Validates commit hashes before generating links, so you never get a broken URL
Multi-threaded scanning - set the thread count to match your hardware
Three output formats: human-readable text (with color-coded terminal output), JSON, or CSV
Stream-based processing to keep memory usage low even on large histories
Modern, safe filesystem operations: Uses C++20 std::filesystem for all path handling, eliminating platform-specific path issues and improving security
Direct Git integration: Leverages libgit2 for efficient, safe repository operations without spawning subprocesses

Example output

[1/7] Scanning: ccas-website
[INFO] Cloning repository (depth=100)...
[INFO] Scanning history...
[WARN] Found 5 potential environment/configuration files:
     - client/assets/js/config.js
       [LINK] https://github.com/.../blob/c7e0fba.../client/assets/js/config.js

Each finding links straight to the offending commit, so remediation is one click away instead of a history-diving expedition.

Getting started

git clone https://github.com/gerald-mathew/github-secrets-watcher
cd github-secrets-watcher
mkdir build && cd build
cmake ..
make

Then run a scan:

./github_secrets_watcher scan --username YOUR_USERNAME

Add a token for private repos and higher API rate limits:

./github_secrets_watcher scan --username YOUR_USERNAME \
  --token YOUR_PERSONAL_ACCESS_TOKEN --include-private

You can tune the scan with --depth, --max-repos, --threads, --format, --verbose, repo(s) <repo name(s)> and --output.

Why C++20

This isn't a wrapper around git log piped through grep — it uses libcurl for GitHub API calls, libgit2 for direct Git repository access, nlohmann/json for parsing, and C++17 std::filesystem for safe, portable path operations, with modern C++20 features throughout. It builds cleanly with CMake or a provided build script on Linux, macOS, and Windows (via MSYS2).

Try it out

It's MIT-licensed and open source. If you've got repos going back a few years, there's a decent chance something's buried in there that shouldn't be — I'd genuinely be curious what people find.

🔗 github.com/gerald-mathew/github-secrets-watcher

Feedback, issues, and PRs welcome.

Update - Sep 3:

Based on feedback from the community, I’ve replaced the filesystem handling with std::filesystem and am now using libgit2 for Git operations instead of popen. Thanks to @hailiang194 for the suggestions!

Jev & computer-use

Tue, 29 Sep 2026 14:14:02 +0000

Current work: jev-computer-use

My TL for the last few days has been taken over by Jev, a system one model from typesafe.ai. So i applied for the waitlist and got in.

To me a interesting use-case for this kind of model is on browser/computer-use, lot of decision to be taken which may not need long reasoning before doing so, the UX improves with the speed we get and automations feel right.
Checkout the jev-ultrafast by browser-use.

Take a general purpose model (GPT / Claude), the lifecycle of a understand user request looks like:

plan
generate code / text
produce tool calls
something broke / unexpected ? - give the agent new state ask it to redo stuff.

This is useful when the task isn't fully known in advance, involves long reasoning and time. But think of structured inputs like forms or OS accessibility, the decisions of what needs be done given a goal is more local than you think.

What is Jev?

This could be very simply put as a classifier. The model accepts a state and questions returns a typed decision. A state is your structured text input and questions have three primitives:

Choice: picks one of the options you provide + confidence
Score: rate something you provide + confidence
Noul: yes / no with a probability

General purpose LLMs are also capable of it but the main difference here is - jev exposes a decision interface rather text generation interface, give the context and decision to make, received a typed result.

Think of making your agent logic as state machines, give that state, goal and the choices it can trigger, this works really well.

On computer-use

There are multiple ways to do this:

Screenshot, use a model for segmenting and OCR then convert to structured format pass it to JEV for decision
OR the OS itself provides accessibility APIs to navigate, its already structured use it directly

I'm currently experimenting on this: jev-computer-use

A example computer-use flow:

Claims and things to look out for

Although the model is refreshing in the age of LLMs, i think the magic lies in the data, they do claim they are a data research company first and it's been trained on 100% synthetic data.

There is one more strong claim on almost no hallucination, being type safe does not guarantee that.
If you think this run deterministically, NO, same prompt gives you different probabilities every run.

Confidence score is a derived metric which is tightly coupled with the classification scores. So it may not be the right measure for whatever you are doing and you are are open to come up with any definition for the confidence using the probabilities list.

FireMigrate: leave Firebase for Postgres without dumping everything into JSON

Tue, 22 Sep 2026 04:51:20 +0000

It’s a small MIT CLI. The interesting work is still open.

Most Firebase → Postgres guides do the same thing: export the project, stuff documents into a jsonb column, call it migrated. You kept the data and lost the shape.
FireMigrate does the opposite. It reads Firestore and Firebase Auth first, prints a relational schema you can argue with, and refuses to write until you say so.

npx @ezekielreu6/firemigrate init
npx @ezekielreu6/firemigrate inspect
npx @ezekielreu6/firemigrate schema
npx @ezekielreu6/firemigrate migrate --dry-run

Website
npm
Repo

Why this exists
Firestore is a document store. Postgres is tables, types, and foreign keys. A real move has to admit uncertainty:
this field is a string in 80 documents and a number in 4
this userId looks like a reference
this collection has nested subcollections the sample never saw
FireMigrate treats those as warnings, not as something to hide in JSON.
What it does today
The package on npm is @ezekielreu6/firemigrate (currently 0.1.3). MIT. CLI-first. Node 20+.
Command

What actually happens

init
Writes firemigrate.config.json and .env.example. Will not overwrite unless you pass --force.
inspect
Read-only. Collection counts, sampled field types, mixed-type warnings, Auth provider summary.
schema
Prints Postgres SQL. One table per top-level collection. Mixed/maps/arrays → jsonb. Timestamps → timestamptz.
migrate --dry-run
Default. Streams documents, reports counts, writes nothing.
migrate --write
Only if the flag and "dryRun": false are set. Creates tables, upserts by id in batches, then checks row counts.

verify

Compares Postgres row counts to Firestore document counts.
Credentials live in env vars (FIREBASE_PROJECT_ID, FIREBASE_CLIENT_EMAIL, FIREBASE_PRIVATE_KEY, DATABASE_URL). The config file starts empty on purpose. Do not commit service-account keys.
What is still sharp (this is the contributor pitch)
This is an early foundation, not a complete migration product. That is the point of the repo.
Open work, if you want a useful PR:
Subcollections — detected, not migrated. Need a mapping that becomes real tables instead of a JSON blob.
Better relationship guesses — name-based FKs should stay warnings until confidence is high. Improve the analyzer, don’t silently emit fake constraints.
Auth users — inspect already summarizes providers. Actual Auth → Postgres (no plaintext passwords) is unbuilt.
Storage — not covered.
Sample bias — schema is inferred from up to 100 docs/collection (max 1000). Fields outside the sample get dropped and reported. Smarter sampling would help.
Tests — domain tests for inspect/schema/migrate, with fake fixtures and no real credentials.
Docs of edge cases — mixed types, colliding id fields, paused writes, verify mismatches.
What we will not merge: a PR that writes to the destination by default, logs private keys, or fakes inspect output.

Repo shape

packages/core inspect, schema, migrate, verify
packages/cli the firemigrate binary
Local loop:
pnpm install
pnpm build
node packages/cli/dist/packages/cli/src/index.js inspect
Small PRs. One adapter or one workflow change at a time. Keep dry-run as the default.
If you only have 20 minutes
Run init + inspect on a throwaway Firebase project. File an issue with:
what the inspect report got wrong
a redacted collection shape (field names + types, not documents)
what you expected the schema to look like
That kind of issue is more useful than a star.
If you want to implement something, open the issue first so two people don’t build the same subcollection mapper.
FireMigrate is for people who are leaving Firebase on purpose, not for people who want a magic dump. If that sounds like work you already do, the repo is here:
Repo

How OpenAI Codex let me down — and why I built Codey, an open-source coding assistant

Tue, 28 Jul 2026 15:59:08 +0000

When OpenAI announced Codex and CLI tools, I got excited — finally, an easy way to automate coding workflows using LLMs!
I bought credits, installed the CLI, and even set it up on my Mac.

But... it didn't go smoothly.

First, I realized Codex CLI only supports Mac and Linux. Okay, not ideal but manageable.
Then, I found out that cheaper models like gpt-4o-mini don't even support shell commands.
(If you try, you get ENOENT errors because tool calls are missing.)

I thought: maybe switching to o4-mini would fix it.
Nope — new accounts don't have access immediately. I was stuck.

Instead of waiting endlessly, I decided to build my own CLI assistant from scratch — and that's how Codey was born!

What is Codey?
Codey is a Python-based, open-source coding assistant that uses OpenAI's API — but defines all tools explicitly for safety and control.

It supports:

File Management: Create, edit, and read files with tools like create_file, edit_file, read_codebase

Git Operations: Add, commit, check status, view diffs, and more

Utilities: Search files (grep) and calculate expressions safely

Shell Commands: Run shell commands inside your environment securely

Why build it myself?
I wanted predictability — knowing exactly what a tool can and cannot do.

I wanted local safety — no random shell execution unless I allow it.

I wanted modularity — easily extend or customize based on project needs.

And honestly... I just wanted something that works reliably without mysterious permission errors.

Codey is Open Source
You can check it out here:
https://github.com/Varad-13/codey

If you want to try it out, suggest features, or even contribute (we need to add a million more tools) — you're welcome!

Git Worktrees Are Underrated

Sat, 18 Jul 2026 22:31:32 +0000

If you've ever stashed half-finished work to review a PR, or lost a train of thought switching branches, you should know about git worktrees. They've been in git since 2015, but most developers I talk to have never heard of them.

The problem with branches

The standard git workflow is linear. You're on a branch, you need to context-switch, so you stash your changes (or worse, make a throwaway commit), switch branches, do your thing, switch back, and pop the stash. If you're lucky, nothing conflicts.

This gets worse when you're juggling multiple things at once. Reviewing a colleague's PR while your feature branch is mid-refactor. Running tests on one branch while coding on another. Hotfixing production while your main work sits frozen.

A git repository has one working directory. One branch checked out at a time. Everything else has to wait.

Worktrees

Git worktrees let you check out multiple branches simultaneously, each in its own directory. They share the same .git history and objects, so you're not cloning the entire repo, but each one has its own working directory and index.

git worktree add ../feat-login feat/login

Now feat/login is checked out in ../feat-login. You can open it in a separate editor window, run tests there, or just let it sit while you work on something else.

When you're done:

git worktree remove ../feat-login

Why nobody uses them

If worktrees are so useful, why aren't they more popular? I think it comes down to two things.

First, the directory problem. Every time you create a worktree, you have to pick a path. There's no convention for where they go. After a week you end up with directories scattered across your filesystem: ../feat-login, ~/tmp/hotfix-auth, ../../pr-review. Good luck remembering where anything is.

Second, there are no ergonomics. You can't easily list your worktrees with status info, cd into one quickly, or run something like npm install in the new directory after checkout. The raw git commands work, but they don't make worktrees feel like a real workflow.

These aren't fundamental problems with worktrees. They're tooling gaps. That's why I built arbor.

A better workflow with arbor

Arbor is a CLI that manages git worktrees. It keeps them organized in a central directory (~/.arbor/worktrees/) and handles the stuff that plain git doesn't.

# Clone a repo (sets up a bare repo + default branch worktree)
arbor clone user/my-app

# Create a worktree for a new feature
arbor add feat/login

# Shell integration auto-cds you into the worktree
# You're now in ~/.arbor/worktrees/my-app/feat-login

# Need to review a PR? Open another worktree
arbor add fix/auth-bug

# See all your worktrees with dirty/clean status
arbor ls

Every worktree for my-app lives under ~/.arbor/worktrees/my-app/. Branch slashes become dashes in directory names, so the filesystem stays tidy. When you're done with a branch:

arbor rm -d feat/login

That removes the worktree and the local branch in one step.

What makes it stick

I've been using worktrees for a while, but I kept falling off because of the friction. A few things in arbor made the difference for me.

Shell integration. arbor init sets up a wrapper so that arbor add and arbor switch automatically cd you into the worktree directory. Without it you create the worktree and then have to cd into it yourself every single time, which gets old fast.

Post-create hooks. You can add an .arbor.toml to your repo:

[hooks]
post_create = "npm install"

Every new worktree gets its dependencies installed automatically. You can chain commands too:

[hooks]
post_create = ["npm install", "cp .env.example .env"]

And arbor ls --all shows the state of every worktree across all your repos, which is nice for a quick scan before you call it a day.

Where I use them most

PR reviews. arbor add the branch, review it in a separate editor window, remove it when done. My own work is untouched.

Long test suites. Tests running on one branch, coding on another. No waiting around.

Hotfixes. arbor add hotfix/critical, fix it, push it, remove it. Back to what I was doing.

Comparing behavior. Two worktrees open side by side, one on main and one on my feature branch. Way easier than switching back and forth.

Big migrations. Upgrading a framework to a new major version in a worktree while the rest of the team keeps shipping from main, the way I kicked the tires on SolidJS 2.0 and dug into its async data model. No half-broken build blocking anyone.

Git worktree best practices

A few habits keep worktrees from turning into the mess that makes people give up on them, whether you're on arbor or raw git.

Keep them in one predictable place. Pick a home for your worktrees and stick to it: a ~/worktrees/ directory, or let arbor manage ~/.arbor/worktrees/ for you. Scattering them across ../, ~/tmp, and ../../ is how you lose track of what lives where.

One branch per worktree. Git won't let you check out the same branch in two worktrees without --force, and that guardrail is worth respecting. Keep the mapping one branch to one directory.

Create the branch and the worktree together. git worktree add -b feat/login ../feat-login makes the branch and checks it out in the new directory in a single command, instead of creating the branch first and adding it after.

Remove worktrees with git, not rm -rf. Run git worktree remove ../feat-login instead of deleting the directory by hand. A manual delete leaves stale metadata behind in .git/worktrees, which you then have to clear out with git worktree prune.

Run git worktree list when you lose the thread. It prints every worktree with its branch and commit, so you can see what's checked out where before you go hunting through directories.

Don't nest them. Give each worktree its own top-level directory rather than tucking one inside another worktree or the main repo. Nesting confuses tooling, and worktrees on a repo with submodules are only partly supported anyway.

Try it

Arbor is open source, written in Rust. Install with Homebrew:

brew install morellodev/tap/arbor

Or grab a binary from the releases page.

Run arbor init after installing to set up shell integration. Takes about 30 seconds.

If you've never tried worktrees, give them a shot. And if you have but gave up because of the directory mess, this might be worth another look.

The repo is at github.com/morellodev/arbor.

They Asked for My AI Rules. But I Could Not Just Hand Them Over.

Mon, 13 Jul 2026 18:56:49 +0000

A team lead announces that the team will start using AI-assisted development. Everyone nods. Nobody asks what that actually means on Monday morning.

Some times ago I was in that position. A project I was working on needed to start using AI-assisted development, and the team was new to it. Nobody had rules written down for an agent to follow. Nobody had skills defined for it to load. There was no shared idea of how this should work inside our specific repo. Someone had to go first. That someone was me.

The rules worked because I built them for one repo

I spent time curating a set of rules and skills for that project. Not generic ones. I shaped them tightly around how that repo was actually structured, its conventions, its layout, the things a new engineer usually has to learn by asking around. I wanted an agent working inside that codebase to already know what a human teammate would have picked up in the first two weeks.

I gave a demo. It landed well. Well enough that it got shared further across team, as something other teams could learn from.

I gave the demo again. Same reaction. Then a few developers reached out for the actual rules and skills files.

I said sure, and then I actually looked at what I would be handing them.

The problem showed up the moment other people wanted in

It was not copy-paste-able. The rules referenced folder names, module boundaries, and patterns specific to one repo. Handing them over as-is would have meant handing over advice that was wrong for their project, dressed up as a shortcut.

So I told them to use it as a reference. Look at the structure, understand the reasoning, adapt it to your own repo.

That is correct advice. I watched people nod at it and then quietly missing it.

I was solving the wrong problem the whole time

I had been thinking about this as a documentation problem. Write good rules, explain them well, let people copy the idea. What I actually had was a generation problem. The rules that worked were the ones rendered specifically for a stack, not the ones written generically and left for someone to translate.

The thing that was supposed to spread across other teams did not land as expected. What reached them was a reference nobody had time to turn into anything real. That gap sat there whether I looked at it or not.

What I wanted to build was not another generic harness. I wanted something that looked at a repo's actual stack and produced rules and skills that worked from day one, not rules that needed a translation step before they were useful.

Nobody on a team agrees on one AI tool

Once I sat with that problem, a second one showed up right behind it, and this one turned out to matter just as much.

Every adoption plan I had seen quietly assumed one AI tool per team. In practice, that assumption breaks almost immediately. One engineer wants Cursor. Another has already built muscle memory in Claude Code. Someone else is testing Windsurf, or is stuck on Copilot because that is what the company licensed, or wants to try Antigravity because something new just came out.

Nobody wants to be told which editor or which agent to use, and forcing a single choice on a team is its own kind of friction, separate from the rules problem entirely. An adoption effort that only works for one tool is not really team adoption. It is one person's adoption, dressed up as a rollout.

What the tool had to actually do

That is the shape the problem ended up taking. Not "write better rules." Generate rules and skills that are rendered for a specific stack, and make sure they work no matter which of the tools a given engineer has already chosen.

That is what became FARE and BARE, frontend and backend AI starter recipes, published as npm CLI tools. Point either one at a project and it generates rules, skills, and workflow context shaped around that project's actual stack, with adapters for five tools out of the box: Cursor, Claude Code, Windsurf, Copilot, and Antigravity. The output is meant to be used immediately, not adapted first.

The part worth being honest about is that this did not remove the original judgment call. Something still has to decide what "good rules for this stack" means because it's always well opinionated. The CLI just means that decision gets made once, by the tool, instead of once per engineer, per project, under deadline pressure, with wildly inconsistent results.

I did not build everything I wanted to

The scope I first sketched out was larger than what shipped. There were ideas around deeper project-specific customization, additional integrations, and more automated context tracking that I dropped or pushed to later releases. Some of that was a reasonable v1 boundary. Some of it was me wanting to build the interesting version instead of the useful one, and catching myself doing it.

Keeping it simple was not the easy default. It was a decision, and one I had to make more than once while writing it.

I do not know yet whether this is the right shape for other teams' problems or just the right shape for the one I kept running into. If you try FARE or BARE on your own project, I would genuinely like to know where it holds up and where it does not.

Awaiting your feedback!
Frontend Ai starter REcipes
Backend Ai starter REcipes

Cava segfaulting inside WezTerm (Flatpak)? Diagnosis and fix in one command

Fri, 12 Jun 2026 18:21:18 +0000

cava runs fine in any terminal — but inside WezTerm installed via Flatpak it crashes with:

Segmentation fault (core dumped)

If that's what brought you here, the quick fix is right below. The full diagnosis comes after, for those who want to understand why.

⚡ TL;DR — Fix in two commands

flatpak update org.wezfurlong.wezterm
flatpak override --user org.wezfurlong.wezterm --device=all

Close all WezTerm windows and reopen it. cava should work normally now.

⚠️ Security tradeoff: --device=all grants WezTerm access to all system devices — including camera and microphone, not just audio. If that's a concern in your environment, the safer alternative is to use the native WezTerm build, which doesn't have this restriction by design.

🔍 What's happening under the hood

Why does WezTerm Flatpak cause the crash?

Flatpak runs WezTerm inside a sandbox that isolates the process from the host system. cava tries to enumerate available audio devices (ALSA/PipeWire) right at startup — without access to those device nodes, it receives an invalid pointer and segfaults.

That's why other terminals (GNOME Terminal, Kitty, etc.) don't have this problem: they have unrestricted access to the system. --device=all fixes exactly that: it grants access to the audio device nodes cava needs to initialize.

As a secondary hypothesis (not directly confirmed), the sandbox may also modify environment variables that cava uses to detect the audio backend.

Confirming with GDB

Want to see the full backtrace? Expand here.

Inside WezTerm, run: ```bash gdb cava ``` When prompted, accept debuginfod with `y`. Then: ``` (gdb) run ``` When the crash occurs: ``` (gdb) bt ``` The output should look something like this: ``` Program received signal SIGSEGV, Segmentation fault. __strncmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283 283 VMOVU (%rdi), %ymm0 (gdb) bt #0 __strncmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283 #1 0x0000555555559cfe in main (argc=, argv=) at /usr/src/debug/cava-0.10.2-7.fc44.x86_64/cava.c:297 ``` The crash happens inside `__strncmp_avx2` — a glibc string comparison function — called by `cava` at line 297. The pointer passed in is null or points to invalid memory, which indicates that `cava` failed to retrieve valid information about the audio devices and segfaulted when trying to use it.

✅ Step-by-step fix

1. Update your packages

sudo dnf upgrade cava          # Fedora
flatpak update org.wezfurlong.wezterm

2. Grant device access

flatpak override --user org.wezfurlong.wezterm --device=all

3. Fully restart WezTerm

Close all windows and reopen. Ctrl+Shift+R is not enough — Flatpak permission changes only take effect after a full restart.

4. Test it

cava

🎉 Working? You're done. If not, see the alternatives below.

🖱️ Alternative: Flatseal

Prefer a GUI for managing Flatpak permissions?

flatpak install flathub com.github.tchx84.Flatseal

Open Flatseal → select WezTerm → go to the Device section → enable All devices → restart WezTerm. The result is identical to the command above.

⚠️ If it still doesn't work

Audio service not running: check if PipeWire is active:

systemctl --user status pipewire
# If inactive:
systemctl --user start pipewire

Rendering issue: add this to your ~/.wezterm.lua:

config.front_end = "Software"

⚠️ This option may cause slowness or even prevent WezTerm from opening on some systems. Use with caution.

🔄 Last resort: native WezTerm

If nothing works — or if the --device=all tradeoff isn't acceptable — the native build solves it definitively: no sandbox, no device restrictions.

The official documentation covers all options: AppImage, .deb/.rpm packages, and building from source.

📌 Summary

Solution	Complexity	Keeps Flatpak?
`flatpak override --device=all`	⭐ Low	✅
Flatseal (GUI)	⭐ Low	✅
Check PipeWire	⭐⭐ Medium	✅
`front_end = "Software"`	⭐⭐ Medium	✅
Install native build	⭐⭐ Medium	❌

The root cause is the Flatpak sandbox blocking cava's access to audio device nodes at startup. Releasing that access with --device=all resolves it in almost every case — and you keep all the benefits of Flatpak.

📝 Based on real experience on Fedora 44+ with WezTerm (Flatpak) and cava 0.10.2.

rdev-go-ddgen: Automating Domain Directory Boilerplate for Go Applications

Wed, 10 Jun 2026 15:27:33 +0000

When building robust backend APIs in Go, maintaining a consistent, clean architectural pattern across domain directories is essential for scalability. However, manually creating repetitive domain structures for every new resource introduces subtle human error.

The Why: Why Manual Boilerplate Fails Copy-pasting existing files to scaffold a new domain (e.g., adding an orders domain next to a users domain) is a common but fragile practice. It is incredibly easy to overlook an import statement, miss a file, or forget to update a variable definition. As an API grows to dozens of domains, this manual approach becomes a major bottleneck that risks introducing compilation errors or silent bugs into your application.

The What: What is rdev-go-ddgen? rdev-go-ddgen (Domain Directory Generator) is a lightweight, open-source Command Line Interface (CLI) tool designed to eliminate manual boilerplate creation for Go applications. It targets developers looking to instantly spin up predictable, structured domain directories without the risk of copy-paste mistakes.

While built out of a personal need while developing high-conformance Go APIs using Gin and Bun ORM, rdev-go-ddgen is completely engine-agnostic and serves as a universal foundational bootstrapper.

The How: Rapid Deployment You can install rdev-go-ddgen globally and immediately integrate it into your development workflow with a single command:

go install github.com/XaiPhyr/rdev-go-ddgen@latest

To Initialize folder structure

rdev-go-ddgen init

To scaffold a completely new, structured domain directory, simply initialize the tool and use the domain flag (-d):

rdev-go-ddgen -d orders

This single command instantly generates a pristine directory containing five core architectural layers, fully stubbed with basic functions and type declarations:

handler.go – API routing and transport logic. service.go – Core business logic boundaries. repository.go – Database abstraction and data access. types.go – Domain-specific data models and structs. _test.go – Unit and integration test placeholders.

P.S. I hope this tool saves you some development time! rdev-go-ddgen is my first official contribution to the Go community, it’s a small step, but I’m incredibly excited to finally share something back with the ecosystem.

Your Codebase Is Too Big for an AI. Here's How to Give It Only What Matters

Wed, 10 Jun 2026 04:54:51 +0000

Every AI session I had started with the same silent ritual.

Open the project. Figure out which files are actually relevant. Remember to skip node_modules. And __pycache__. And .venv. And the lock files. Zip everything manually. Find the zip. Upload it. Then type out what I was actually trying to do, context the AI had no way of knowing.

It was maybe 5 minutes. Not a crisis. But it happened every single session, and at some point I stopped accepting it as normal.

So I built contextzip.

{% embed https://youtu.be/mHq1JH0ZJuY %}

What it does

contextzip is a CLI tool that packages exactly the right parts of your codebase into a ZIP, ready to drop into Claude, ChatGPT, or any other AI tool.

Install it once:

pip install contextzip

Then from any project:

cd your-project
contextzip

That's it. It detects your stack automatically : Next.js, Django, FastAPI, Rust, Go, Ruby, and more, applies the right exclusion rules for each, respects your .gitignore, and drops a clean ZIP into .contextzip/ at your project root. Your file manager opens with the archive already selected.

The part I'm most excited about

contextzip --prompt "Change toast color on failed login"

Describe your task in plain English. contextzip builds a lightweight file map of your project and asks Gemini to return only the files relevant to that specific task. Usually 2 to 5 files. Not your entire codebase.

The ZIP also includes a prompt.txt with your task description, so when you drop it into an AI tool, the context is already there. No retyping, no re-explaining.

This is the feature that changed how I personally work with AI tools day to day.

First-time setup: --prompt requires a free Gemini API key from Google AI Studio, no credit card needed. contextzip walks you through it on first use.

Other things it does

--git-changes

Only package files that git considers modified, staged, or untracked. Perfect for incremental debugging sessions and PR reviews where you don't need the whole project, just what changed.

contextzip --git-changes

watch mode

This one is underrated. Wrap your dev server with contextzip watch and it buffers the output in the background, watching for errors. The moment one appears, a prompt shows up beneath it:

╭─ contextzip · error detected ─────────────────────╮
│  Press [D] to package debug context  [S] to skip  │
╰───────────────────────────────────────────────────╯

Press D. A debug-ready ZIP lands in .contextzip/ with the error, the stack trace, and the relevant source files already inside. Your server keeps running, no restart needed.

contextzip watch -- npm run dev
contextzip watch -- python manage.py runserver

Smart exclusions by framework

contextzip stacks exclusion rules based on what it detects:

Stack	Excluded automatically
Node.js / Next.js	`node_modules/`, `.next/`, `dist/`, lock files, `*.min.js`
Python / Django / FastAPI	`__pycache__/`, `.venv/`, `*.pyc`, `migrations/`, lock files
Rust	`target/`, `Cargo.lock`
Go	`vendor/`, `go.sum`, `bin/`

A monorepo with both package.json and pyproject.toml gets both rule sets applied automatically.

Honest limitations

--prompt requires a free Gemini API key
watch doesn't use PTY emulation, so color passthrough on Windows is limited
AI file selection is capped at 10 files by design, the goal is tight context, not comprehensive coverage

Try it

pip install contextzip

GitHub: github.com/akadeepesh/contextzip

MIT licensed, open source.

If you've been living with this friction and didn't realize it was fixable, now you know. And if you try it, I'd genuinely love to hear how it fits into your workflow.

I built a CLI that eliminates README reading forever

Mon, 01 Jun 2026 10:05:12 +0000

title: I built a CLI that eliminates README reading forever
published: true
description: rex detects your project stack and runs the right command. Zero config. One binary. 12 ecosystems.
tags: go, cli, productivity, opensource

cover_image: https://rexrun.dev/logo.png

The problem

Every developer knows this pain:

Clone a repo
Want to run the tests
Open the README
Scroll... scroll... find a "Development" section... maybe
Figure out it's pnpm test (not npm test, not yarn test)
Run it wrong anyway because you needed pnpm install first

Multiply this by every repo you touch. Every PR you review. Every onboarding.

I got tired of it.

The solution: rex

git clone https://github.com/some/repo
cd repo
rex test

That's it. Rex looks at your project files, detects the stack, and runs the correct command. No config. No setup. No reading anything.

How it works

Rex reads files in your project root:

File found	Stack detected	`rex test` runs
`go.mod`	Go	`go test ./...`
`package.json` + `pnpm-lock.yaml`	Node + pnpm	`pnpm test`
`Cargo.toml`	Rust	`cargo test`
`pyproject.toml` + `uv.lock`	Python + uv	`uv run pytest`
`composer.json` + `artisan`	PHP + Laravel	`php artisan test`
`Gemfile` + `app/`	Ruby + Rails	`bundle exec rails test`
`pom.xml`	Java + Maven	`mvn test`
`build.gradle`	Java + Gradle	`./gradlew test`
`build.zig`	Zig	`zig build test`
`mix.exs`	Elixir	`mix test`
`Makefile`	Make	`make test`
`Justfile`	Just	`just test`

12 ecosystems. It also detects which package manager you use by looking at lockfiles.

Demo

Watch the video demo

$ cd my-go-project/
$ rex

  my-go-project

  stack  go

  commands
    rex test   go test ./...
    rex run    go run ./cmd/server
    rex build  go build ./...
    rex deps   go mod download
    rex fmt    gofmt -w .
    rex lint   go vet ./...

$ rex test
> go test ./...
ok   github.com/example/app   1.2s

The > arrow always shows exactly what rex will run. Full transparency.

All the verbs

Command	What it does
`rex test`	Run tests
`rex run`	Start the app / dev server
`rex build`	Build the project
`rex deps`	Install dependencies
`rex clean`	Remove build artifacts
`rex fresh`	clean, deps, build in sequence
`rex fmt`	Format code
`rex lint`	Lint code
`rex clone <url>`	Clone + detect + install deps in one command
`rex init`	Generate rex.toml for your team
`rex doctor`	Diagnose environment issues

Killer feature: rex clone

rex clone https://github.com/someone/project
# cloning...
# detected: node + pnpm
# deps: pnpm install
# ready! cd project && rex run

From URL to working project in one command. No README needed.

Monorepo support

Rex auto-detects monorepos (packages/, apps/, services/):

$ rex

  my-monorepo (monorepo)

  workspace  3 sub-projects detected

    packages/api         node + pnpm
    packages/web         node + pnpm
    services/auth        go

Team workflow: rex init

rex init
# created rex.toml (go project)

Generates a rex.toml from detected commands. Commit it. Now every teammate runs the same commands without asking.

.env loading

Rex automatically loads .env files before running commands. No extra tools needed.

Why I built this

I maintain projects across Go, Node, Python, and Rust. I context-switch between repos dozens of times per day. The cognitive load of remembering pnpm test vs go test ./... vs cargo test is small individually, but it adds up.

Rex makes every repo feel the same:

rex test   # always works
rex run    # always works
rex build  # always works

It's the muscle memory tax I no longer pay.

Technical details

Single binary, no runtime, no dependencies
Written in Go, cross-platform
Less than 50ms startup, faster than your shell prompt
Zero network calls, fully offline
Correct exit codes, works in CI
Shell completions for bash, zsh, fish
Apache 2.0 license
Mentioned in Awesome Go

Install

# Homebrew (macOS/Linux)
brew tap rexrun-dev/tap && brew install rex

# Go
go install rexrun.dev/rex/cmd/rex@latest

Or grab a binary from GitHub Releases.

I built an AI Agent that lives directly in your CLI and Desktop

Wed, 20 May 2026 04:16:38 +0000

I built an AI Agent that lives directly in your CLI and Desktop

Most AI coding workflows still feel disconnected.

You copy code from your editor → paste into ChatGPT/Claude → copy the answer back → repeat.

I got tired of acting like a middleman between my codebase and AI tools, so I built Mint

Mint is a unified AI desktop assistant + autonomous coding CLI designed for developers who want:

Local-first workflows
Agentic coding
MCP extensibility
Workspace-aware AI
Transparent safety controls

What Mint can do

Unified AI CLI Agent

Mint is not just a chat wrapper.

It can:

inspect your workspace
search code
read/write files
apply patches
execute shell commands with approval
stream live responses directly in the terminal

Example:

mint code "find the memory leak in the auth module and patch it"

Desktop Assistant

Mint also includes an Electron desktop assistant with:

Screen vision
Real-time translation
Floating assistant UI
Live2D assistant model
Proactive local suggestions
Automation workflows

MCP Support

You can extend Mint using Model Context Protocol servers:

mint mcp add google-search npx --args -y @modelcontextprotocol/server-google-search

Multi-Provider Support

Mint supports:

Gemini
OpenAI
Claude
Ollama
LM Studio
Local OpenAI-compatible providers

Safety First

One thing I care about a lot is transparency and control.

Mint:

asks permission before shell commands
blocks dangerous commands
prevents unsafe path traversal
keeps local action logs

Why I built it

I wanted an AI assistant that actually feels integrated into the developer workflow instead of existing in a separate browser tab.

Something fast.
Something local-first.
Something extensible.
Something that feels like a real co-developer.

GitHub

GitHub: https://github.com/Pheem49/Mint

Would love feedback from other developers working on AI agents, local models, or terminal workflows

Ditch the Clunky GUIs: Meet ComChan, the Blazingly Fast Rust Serial Monitor

Fri, 15 May 2026 15:58:16 +0000

If you spend any significant amount of time doing embedded systems development, you know the drill. You write your firmware, flash the microcontroller, and then… you stare at a serial monitor.

For years, the options have been a bit of a mixed bag. You have the classic Arduino IDE Serial Monitor (which is functional but basic), bloated GUI protocol analyzers that eat up RAM, or simple CLI tools like minicom that get the job done but lack modern developer quality-of-life features.

As someone who lives in the terminal—relying on tools like Neovim and terminal multiplexers—I wanted a serial monitor that actually fit into a keyboard-driven, modern workflow. I wanted something lightweight, visually clean, and capable of handling complex data without breaking a sweat.

So, I built ComChan (Communication Channel).

What is ComChan?

ComChan is a minimal, blazingly fast serial monitor and plotter built entirely in Rust. It’s designed specifically for embedded systems engineers who want powerful data visualization and logging without leaving the command line.

Because it's written in Rust, it’s memory-safe, incredibly fast, and runs natively across Linux, Windows, and macOS.

Here is a look at the features that make ComChan stand out from the crowd.

1. The Terminal-Based Serial Plotter

Sometimes, raw text isn't enough. When you are debugging an IMU, reading ADC values, or tracking temperature sensors, you need to see the data visually.

Instead of exporting data to Excel or firing up a heavy GUI application, ComChan features a built-in TUI (Terminal User Interface) plotter. You simply pass the --plot flag, and ComChan will automatically parse your incoming numeric data, assign legends, and graph multiple sensor channels in real-time—right inside your terminal.

Found a spike you want to investigate? You can hit Ctrl+S to instantly export the current plot frame as a clean SVG file.

Here is how it'll look like

2. Time Travel with Session Replay

This is perhaps my favorite feature. Debugging intermittent hardware anomalies is a nightmare because you can't always recreate the exact physical conditions that caused the bug.

ComChan introduces Session Replay. You can log your raw serial output to a .log or .csv file during a test run. Later, you can run comchan --replay <file> and the tool will parse the timestamps and play the data back to you in real-time.

It perfectly recreates the exact timing of the original hardware run. You can even replay a log file directly into the visual Plotter to analyze the anomaly visually, without needing the physical microcontroller plugged in.

3. Continuous CSV Streaming

If you are doing data collection for research or analysis, ComChan can automatically parse your incoming numeric telemetry and stream it directly into a clean, multi-column .csv file on the fly.

The best part? This works concurrently. You can stream to a CSV in the background while actively watching the data on the TUI Plotter.

4. Built for the Modern Embedded Workflow

ComChan includes several smaller features designed specifically to remove friction from the embedded workflow:

Auto-Detection: Tired of typing /dev/ttyUSB0 or COM3? Just use comchan --auto and it will automatically find and connect to your active USB serial device.
Zephyr RTOS Support: If you work with Zephyr, ComChan has a dedicated --zephyr shell mode that handles its specific echo and prompt behaviors cleanly.
Auto-Recovery: If you accidentally unplug your device or reset the power, ComChan won't crash. It detects the broken pipe and gracefully waits to reconnect when the hardware comes back online.
Configuration Files: Save your favorite baud rates, data bits, and parity settings in a .toml file so you don't have to pass a dozen flags every time you launch.

The "Brain Made" Philosophy

While AI tools are great for scaffolding tests or micro-optimizations, the core architecture, TUI design, and feature logic of ComChan are entirely human-crafted. It’s built to solve real pain points that I experience daily when working with memory-safe embedded development on ESP32s and RP2040s.

Try It Out

If you are ready to upgrade your embedded debugging workflow, ComChan is incredibly easy to install.

If you have Cargo installed:

cargo install comchan

For Arch Linux users, it's available on the AUR:

yay -S comchan

You can check out the full source code, read the documentation, and contribute on GitHub: Vaishnav-Sabari-Girish/ComChan

Drop a star if you find it useful, and let me know what features you’d like to see next (a Hex Dump mode is already on the roadmap!). Happy debugging!

I Built fintech-fraud-sim: A TypeScript CLI for Synthetic Fraud Testing Data

Wed, 13 May 2026 20:40:17 +0000

Fraud systems are hard to test well.

Not because engineers cannot write tests, but because the data needs to tell a story. A suspicious transaction is rarely suspicious because of one field. It is usually suspicious because of patterns:

a new account with too many beneficiaries
many transactions in a short window
failed logins followed by a device change
KYC failures mixed with country mismatches
transaction amounts far above normal behavior

Using production customer data for this is risky and often unacceptable. Basic mock data is usually too flat.

So I built fintech-fraud-sim, a TypeScript CLI that generates synthetic fintech users and transactions with configurable fraud patterns.

NPM package: https://www.npmjs.com/package/fintech-fraud-sim

Quick Start

npx fintech-fraud-sim generate --users 1000 --fraud-rate 0.08

That command generates:

users.csv
transactions.csv
users.json
transactions.json
summary.json

You can also choose a format:

npx fintech-fraud-sim generate --users 5000 --fraud-rate 0.12 --format csv

Or send output to a folder:

npx fintech-fraud-sim generate --users 2000 --fraud-rate 0.05 --format json --out ./data

Why I Built It

Fraud detection products need test data in many places:

dashboards
QA fixtures
rules engines
risk scoring services
transaction monitoring demos
analytics pipelines
prototype fraud models

But realistic fraud test data is not just random rows. It needs consistent signals across users and transactions.

For example, an account takeover scenario should not only mark a transaction as suspicious. The user should also show supporting signals such as failed logins, device changes, and country mismatch.

That is the idea behind this CLI.

What the Data Looks Like

Generated users include fields like:

user_id
country
account_age_days
kyc_status
failed_kyc_attempts
device_count
ip_country
declared_country
failed_login_attempts_24h
beneficiary_count_24h
chargeback_count
is_fraud
fraud_pattern
risk_label
reason_codes

Generated transactions include:

transaction_id
user_id
timestamp
amount
currency
channel
beneficiary_id
beneficiary_country
device_id
ip_country
status
is_suspicious
fraud_pattern
reason_codes

The package does not generate real names, emails, phone numbers, BVNs, NINs, or bank account numbers.

Supported Fraud Patterns

The CLI currently supports:

Pattern	Description
`mule_account`	New account, high beneficiary count, rapid funds movement
`account_takeover`	Device change, country mismatch, failed login spike
`velocity_abuse`	Many transactions in a short period
`kyc_abuse`	Multiple failed KYC attempts and inconsistent country data
`chargeback_risk`	Prior chargebacks and high-value transactions
`transaction_spike`	Amount far above user baseline
`cross_border_anomaly`	IP or beneficiary country mismatch
`beneficiary_burst`	Many new beneficiaries within 24 hours

You can select specific patterns:

npx fintech-fraud-sim generate \
  --users 1000 \
  --fraud-rate 0.08 \
  --patterns mule,account_takeover,velocity_abuse

mule is accepted as an alias for mule_account.

Deterministic Generation

For tests and demos, deterministic output is important.

npx fintech-fraud-sim generate --users 1000 --fraud-rate 0.08 --seed demo

The same seed produces the same dataset, which makes the CLI useful in CI and repeatable test suites.

Testing

The project includes tests for:

generating users and transactions
fraud rate handling
seeded deterministic output
zero fraud rate behavior
fraud pattern logic
CSV and JSON writers
CLI execution

Example:

npm test

The test suite uses Node's built-in test runner with tsx, so TypeScript tests can run directly.

Example Use Cases

You can use the generated data to:

demo fraud dashboards
test transaction monitoring rules
validate CSV import workflows
build realistic QA fixtures
prototype risk scoring logic
test data pipelines without exposing customer records

Safety Disclaimer

fintech-fraud-sim is for testing, education, and fraud-model prototyping only. It generates synthetic data and should not be treated as real customer data or used as a production fraud decisioning system.

Final Thoughts

Good fraud testing needs more than random transactions. It needs plausible behavior.

This CLI is my attempt to make that easier for fintech builders, QA teams, and engineers working on risk systems.

NPM: https://www.npmjs.com/package/fintech-fraud-sim

wmux: Run Claude Code, Codex, and Gemini CLI Side by Side on Windows

Tue, 12 May 2026 23:49:25 +0000

TL;DR

If you're coding on Windows and juggling multiple AI CLI agents in a single terminal window — stop. wmux is a native Windows terminal multiplexer that lets you run Claude Code, Codex, and Gemini CLI side by side, with built-in browser automation, an MCP server, and real session persistence. No WSL required.

winget install openwong2kim.wmux

That's it. 30 seconds and you're done.

The problem

macOS devs have had cmux — a tmux-based terminal multiplexer tuned for AI agents — for a while now. Windows devs? We've been stuck with a single terminal tab, Alt+Tabbing between agents, spamming "are you done yet?" into the void.

You could use WSL, sure. But then your PowerShell scripts, Windows-native toolchains, and ConPTY-aware TUIs (hi, Claude Code) start to feel awkward.

wmux fills that gap. It's a native Windows multiplexer built on ConPTY, xterm.js with WebGL rendering, and Electron. No VM, no Linux emulation, no weird path translation.

What it actually feels like

Picture this layout on one screen:

Left pane: Claude Code writing your backend
Right pane: Codex scaffolding the frontend
Bottom pane: Gemini CLI running the test suite
Floating pane: A Quake-style dropdown terminal for quick git status checks

Ctrl+D splits right. Ctrl+Shift+D splits down. Ctrl+N opens a new workspace. Ctrl+1~9 jumps between them. Ctrl+click stitches multiple workspaces into a multiview grid. If you're a tmux person, Ctrl+B gives you a prefix mode with 13 rebindable actions.

The part that actually sold me: browser control

Tell Claude Code "search Google for wmux" and it actually does it. Not via shelling out to curl. Not by pretending. wmux exposes a built-in browser panel connected over the Chrome DevTools Protocol, and the MCP server exposes tools like:

What Claude does	MCP tool
Open browser	`browser_open`
Read page structure	`browser_snapshot`
Click element	`browser_click`
Fill form	`browser_fill` / `browser_type`
Press key	`browser_press_key`
Run JS	`browser_evaluate`
Screenshot	`browser_screenshot`

So a prompt like "search for wmux on Google" becomes:

browser_open → browser_snapshot → browser_fill(ref=13, "wmux") → browser_press_key("Enter")

And it works. Even with React controlled inputs and CJK text — both of which love to break naive automation.

Every browser tool accepts a surfaceId, so each Claude Code session drives its own browser. Run three agents, get three browsers, zero cross-talk.

Agent-to-agent messaging

This is the fun one. wmux exposes a2a_send, a2a_broadcast, a2a_task_send, and friends. Your Claude Code instance on the left can literally ping your Codex instance on the right:

"Hey, I changed the API response shape, regenerate the TypeScript types."

That's not a demo — that's Tuesday.

Stop babysitting your agents

wmux watches terminal output throughput (not brittle pattern matching) and fires desktop notifications + taskbar flashes when:

A task finishes
A process exits abnormally
A dangerous command shows up (git push --force, rm -rf, DROP TABLE…)

Go make coffee. wmux will tell you when to come back.

Session persistence that actually persists

Close wmux. Reopen it. Your sessions are still there, 999K lines of scrollback intact, in the right working directory.

Reboot your machine. Same thing. A background daemon keeps PTY processes alive, dumps scrollback to disk, and auto-starts on login.

This is the part tmux users have been quietly missing on Windows for years.

Security I didn't have to ask for

Token auth on every IPC pipe
SSRF protection (blocks private IPs, file://, javascript:)
PTY input sanitization
Randomized CDP port (no fixed --remote-debugging-port=9222 for anyone to hijack)
Memory pressure watchdog (reaps dead sessions at 750MB, blocks new ones at 1GB)
Electron Fuses locked down (RunAsNode disabled, cookie encryption on)

For a tool that hands AI agents a browser and a shell, this is the bare minimum — and wmux actually does it.

The rest of the goodies

xterm.js + WebGL GPU rendering
Unicode 11 width tables (CJK/emoji actually render correctly in TUIs)
Shell integration via OSC 133 — terminal_read_events gives agents semantic command boundaries, not raw bytes
Regex search (Ctrl+F), Vi copy mode (Ctrl+Shift+X), scroll bookmarks (Ctrl+M)
Smart right-click: selection → copy, empty area → paste, link → Open/Copy menu
Layout templates you can save and restore from the command palette
Themes: Catppuccin Mocha, Monochrome, Sandstone
i18n: English, Korean, Japanese, Chinese
Auto-update via GitHub Releases

Agent detection covers Claude Code, Cursor, Aider, Codex CLI, Gemini CLI, OpenCode, and GitHub Copilot CLI out of the box.

Install

Pick your poison:

# winget (recommended)
winget install openwong2kim.wmux

# Chocolatey
choco install wmux

# PowerShell one-liner
irm https://raw.githubusercontent.com/openwong2kim/wmux/main/install.ps1 | iex

Or grab wmux Setup.exe from the releases page.

Final thought

Windows devs have been the second-class citizens of the AI coding agent world for a minute. wmux doesn't fix everything — but running three agents on one screen, each with its own browser, talking to each other, surviving reboots? That's a genuinely different workflow.

Repo: github.com/openwong2kim/wmux — MIT licensed.

If you try it, I'd love to hear which layout you end up with. Mine is Claude-left / Codex-right / Gemini-bottom, and a floating terminal for git. What's yours?

"Why .NET 9’s CLI is the Glow-up your workflow deserved"

Tue, 05 May 2026 03:26:28 +0000

"From Boring White Text to a Dev Experience That Actually Doesn’t Hurt to Look At".

Let’s be real: for years, the .NET CLI felt like that one reliable but incredibly dull friend. It got the job done, but it had the personality of a spreadsheet. If you’re jumping from .NET 7 or 8, you’re in for a shock. Microsoft finally realized that we spend 90% of our lives staring at a terminal, so they decided to make it look—and feel—like it belongs in 2026.

Here is why you, as a Senior Dev, should actually care about the .NET 9 CLI.

1. The "Visual Soul": Goodbye, Walls of Text

The first thing you’ll notice isn’t a new feature; it’s the Terminal Logger. While it started appearing in .NET 8, in .NET 9 it’s the default, and it is polished.

Progress Bars that actually move: No more guessing if dotnet build is hanging or just thinking.
Clickable Links: Errors now come with direct, clickable links to documentation.
Color-Coded Chaos: Warnings are yellow, errors are red, and successes
are a satisfying green. It sounds minor, but in a massive
microservices build, your eyes will thank you.

Depending on your terminal (like Windows Terminal or Oh My Posh), you’ll see icons for different project types and build stages.

Pro Tip: Use dotnet build --tl (Terminal Logger) explicitly if you’re on a legacy system, but on .NET 9, it’s just there.

2. Automation & "BuildChecks": The Senior’s Safety Net

This is where it gets interesting for those of us managing large codebases. .NET 9 introduces BuildChecks.

Imagine having a linter, but for your .csproj and build logic.

What it does: It analyzes your build process for regressions or "smelly" configurations.
The Command: dotnet build /check
Why it’s useful: It catches things like "Custom task X is slowing
down the build" or "You’re using a deprecated MSBuild property." It’s
basically a code review for your infrastructure.
Git Integration: The CLI is Aware

The .NET 9 CLI is now much more "Git-aware." When you run dotnet new, the SDK automatically detects if you're in a Git repo and can initialize .gitignore files that are actually updated for modern .NET workloads (including stuff for DevContainers and GitHub Actions).

Also, the dotnet workload history command is a lifesaver. If a teammate says, "It works on my machine," you can now check exactly what version of the workloads (MAUI, Aspire, etc.) were installed and when they were updated, making environment parity much easier to debug.

4. Cloud-Native & Docker: The "No-Dockerfile" Revolution

You’re a Senior. You know how to write a Dockerfile. But do you want to?

.NET 9 pushes SDK-based Containerization to the limit. You can now publish a fully optimized, secured, and shrunk Docker image without ever touching a Dockerfile.

dotnet publish /t:PublishContainer -c Release

What’s new here?

Non-root by default: Security is baked in. Images run as a non-privileged user automatically.
Insecure Registries: The CLI now supports pushing to insecure local
registries (great for local K8s testing) without hacking your Docker
config.
Architecture targeting: Easily cross-compile for ARM64 (Graviton/M1) from an x64 machine using just CLI flags.

5. Azure & Aspire: The "Secret Sauce"

If you aren't using .NET Aspire yet, .NET 9 is the sign you were waiting for. The CLI integration with Azure via the azd (Azure Dev CLI) and dotnet aspire commands is seamless.

Smart Provisioning: The CLI can now detect your resource requirements from your code and suggest the right Azure infrastructure.
Deployment: azd up isn't just a gimmick anymore; it uses the .NET 9
SDK to package your apps into container apps with OpenTelemetry
pre-configured.

6. The Advanced "Power User" Commands

For the automation nerds, these are the commands you’ll be scripting into your CI/CD pipelines:

dotnet test --parallel

Now fully integrated with MSBuild for parallel execution across different Target Frameworks (TFM).

dotnet workload sets

Allows you to "lock" a version of the SDK workloads so your whole team stays on the exact same bits.

dotnet tool update

Faster, cleaner, and handles global vs. local tools with better conflict resolution.

What do I think about this?
.NET 9 isn't just about a faster JIT (though it is faster). It's about Developer Joy. The CLI has moved away from being a "black box of text" to a proactive assistant that helps you build, containerize, and deploy without leaving the keyboard.

If you’re still on .NET 7, you’re essentially working in black and white while the rest of us are in 4K. Time to upgrade.

By One Garlos P. 2026

I built a CLI to test Tauri apps because nothing else worked

Tue, 21 Apr 2026 10:31:42 +0000

I spent a weekend trying to set up end-to-end testing for a Tauri v2 app. Two hours into configuring WebdriverIO, I still couldn't get it to connect to the WebView. The official docs show a minimal example that doesn't cover IPC testing. Playwright flat-out doesn't work because Tauri uses WebKitGTK, not Chromium.

I gave up and wrote my own tool.

The actual problem

If you search "Tauri e2e testing" on GitHub, you'll find the same question asked over and over. The official docs split testing into two worlds: Rust unit tests for the backend, and WebDriver-based tests for the frontend. But nobody tells you how to verify that your Tauri IPC commands actually work from the user's perspective. You end up mocking window.__TAURI__ in your frontend tests and hoping production behaves the same way.

It doesn't always behave the same way.

What I wanted was simple: connect to a running Tauri app, inspect the UI, click buttons, fill forms, and check that things happened. Like Playwright, but for Tauri. No WebDriver binary. No Selenium. No 200-line config file.

What tauri-pilot does

tauri-pilot is a Rust CLI that talks to your Tauri app over a Unix socket. You add a plugin to your app (2 lines, debug builds only), install the CLI, and start testing.

$ tauri-pilot snapshot -i
- heading "PR Dashboard" [ref=e1]
- textbox "Search PRs" [ref=e2] value=""
- button "Refresh" [ref=e3]
- list "PR List" [ref=e4]
  - listitem "fix: resolve memory leak #142" [ref=e5]
  - listitem "feat: add workspace support #138" [ref=e6]
- button "Load More" [ref=e7]

That snapshot command walks the accessibility tree and gives every interactive element a short ref like @e3. You use those refs to interact:

$ tauri-pilot click @e3
ok

$ tauri-pilot fill @e2 "workspace"
ok

$ tauri-pilot assert text @e1 "PR Dashboard"
ok

$ tauri-pilot assert visible @e7
ok

Exit code 0 means pass. Exit code 1 means fail with a message. That's it. No test framework to learn.

Setup takes 2 minutes

Add the plugin to your Tauri app:

// src-tauri/src/main.rs
fn main() {
    let mut builder = tauri::Builder::default();

    #[cfg(debug_assertions)]
    {
        builder = builder.plugin(tauri_plugin_pilot::init());
    }

    builder.run(tauri::generate_context!()).expect("error running app");
}

Install the CLI:

cargo install tauri-pilot

Run your app in dev mode. That's it. tauri-pilot ping should respond.

The plugin only compiles in debug builds. It won't end up in your release binary.

Why not just use WebdriverIO?

I tried. Here's what the experience looks like:

With WebdriverIO, you need to install Node.js dependencies, configure wdio.conf.ts, point it at your built binary (not the dev server), make sure the WebDriver binary matches your WebKit version, write tests in JavaScript even though your app is in Rust, and deal with flaky selectors that break when your UI changes.

With tauri-pilot, you run cargo install tauri-pilot, add 2 lines to your app, and start writing shell commands. The accessibility tree refs (@e1, @e2) are stable across renders as long as the element exists. You can use CSS selectors too, or pixel coordinates for edge cases.

The diff command is something WebdriverIO can't do at all:

$ tauri-pilot diff -i
+ button "New PR" [ref=e8]
~ list "PR List" [ref=e4]: children 2 → 3

It compares the current UI state to the previous snapshot and shows only what changed. When you're debugging a UI issue, that's worth more than any assertion framework.

It's built for AI agents

I initially built tauri-pilot so Claude Code could interact with my Tauri apps. The output format is designed for LLM consumption: compact accessibility tree, short refs, plain text responses.

An AI agent's workflow looks like:

snapshot -i to understand the current page
Pick a ref from the output and interact with it
assert to verify the result
diff -i to see what changed without re-reading the entire tree (saves tokens)

The --json flag on every command gives structured output for programmatic use.

But you don't need an AI agent to benefit from this. I use tauri-pilot directly in bash scripts and interactively while developing. It's faster than clicking through the UI manually when I'm testing a form flow for the fifth time.

What's in v0.2.0

The latest release (just shipped) adds:

Record/replay — tauri-pilot record start, interact with your app, record stop --output test.json, then replay test.json to rerun the whole session. Export to a shell script with replay --export sh.
Multi-window support — windows lists all windows, --window flag targets a specific one.
Form dump — forms grabs all form fields at once instead of calling value on each input.
localStorage/sessionStorage access — storage get "token", storage set "key" "value", storage list, storage clear.
Drag & drop — drag @e5 @e6 for sortable lists, drop @e3 --file ./image.png for file upload zones.
DOM watch — watch blocks until a DOM mutation happens, then prints a summary. Good for waiting on async updates.

The full changelog is on GitHub.

How it works under the hood

The plugin starts a Unix socket server when your app launches. The CLI connects to that socket and sends JSON-RPC messages. The plugin injects a JS bridge (window.__PILOT__) into the WebView that handles DOM inspection.

The tricky part was getting return values from webview.eval(). In Tauri v2, eval() is fire-and-forget. There's no way to get a result back directly. So every JS evaluation wraps the script in a try/catch, calls back into Rust via IPC (invoke('plugin:pilot|__callback', {id, result})), and the Rust side waits on a oneshot channel with a 10-second timeout.

It works reliably. I've been running it daily for weeks.

Limitations

Linux only for now. Tauri uses WebKitGTK on Linux, WKWebView on macOS, and WebView2 on Windows. The socket and JS bridge approach should work on all platforms, but I haven't tested it. macOS and Windows support is planned.

The screenshot command uses html-to-image bundled into the JS bridge, which means it captures the WebView content but not native window decorations or system dialogs.

And it's pre-1.0. The API might change. I'm using semver, so minor bumps can include breaking changes until 1.0.

Try it

cargo install tauri-pilot

GitHub: github.com/mpiton/tauri-pilot
Docs: mpiton.github.io/tauri-pilot
crates.io: crates.io/crates/tauri-plugin-pilot

If you're testing a Tauri v2 app on Linux, give it a shot. Issues and PRs are open.

SELinux AVC denied: stop guessing, start fixing

Sat, 18 Apr 2026 13:32:15 +0000

It happens more often than not. A web server gets installed, maybe a database, or perhaps a fresh Podman container. Settings are adjusted carefully, one by one. For testing, permissions shift to 777 — though never on live systems — yet somehow the error persists: Permission denied.

There it is — buried in the logs. That overwhelming chunk of text from SELinux stares back:

type=AVC msg=audit(1612345678.123:456): avc:  denied  { read } for  pid=1234 comm="nginx" name="index.html" scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

Right now, many people online suggest simply typing setenforce 0 or turning off SELinux through /etc/selinux/config without thinking twice. While that might stop the error fast, it weakens system security just to fix a configuration issue. Instead of removing protection entirely, learning what triggered the denial helps find safer fixes.

Some opt for quick workarounds when logs show repeated denials. Yet skipping analysis often leads to broader risks later on. Adjusting policies carefully beats disabling them outright. A temporary bypass may seem helpful — until something else breaks silently.

Here’s something worth considering: turning off SELinux strips away critical protection. When it comes to system safety, removing safeguards rarely helps. Rather than silencing warnings, understanding them makes more sense. Think about it: security tools are there for a reason. What if we focused on interpreting alerts instead? That shift could make all the difference.

The Anatomy of an AVC Denial

Imagine a doorkeeper who ignores names, focusing solely on wristbands. That is SELinux — it disregards regular user access levels entirely. Instead, what matters are assigned tags known as Contexts. Entry depends not on identity but on these specific markers. Rules follow the label, never the person behind it.

Here is what the confusing log actually means:

comm="nginx": A single process moves forward, attempting an action under the name nginx. Like a guest approaching a restricted entrance, it seeks access where entry is controlled.
{ read }: This refers to the operation it aimed to carry out.
name="index.html": This is the target file or object.
tclass=file: Indicates what kind of target is being referenced — could be a regular file, a folder, or even a communication endpoint on a network. Each type changes how operations are applied during processing.
scontext=...:httpd_t:... (Source Context): A process running nginx carries a specific identifier. Labelled as httpd_t, it functions much like an access pass for a visitor. The scontext value reflects what the system sees when checking permissions. Considered part of SELinux enforcement, this tag controls how the process interacts with resources. Assigned automatically, the label determines allowed actions within security policies.
tcontext=...:user_home_t:... (Target Context): A person enters a space only if they meet certain conditions — this file needs approval just like that guest. Access depends on meeting specific criteria, much like an exclusive area allowing entry under set terms. The tag given to index.html acts as such a gatekeeper, determining who fits inside.

The Translation: Not allowed. A web server process attempted to open index.html marked as personal user data. Security policy blocked it immediately. Home areas stay off-limits to public-facing services by design. Reading such files breaks containment rules. The system enforces strict boundaries between service roles and private spaces. Permission revoked based on labeling mismatch alone.

Slow Fixes Take Time

Most of the time, system administrators handle this issue by searching semanage fcontext documentation page by page. Another path is feeding the log data into audit2allow for interpretation.

Most people misunderstand what audit2allow actually does: it won’t repair incorrect file labels. Instead, it creates a tailored policy enabling the web server access to home folders. That approach weakens SELinux instead of strengthening it. Usually, the right move involves adjusting the file context through restorecon or chcon. Altering system-wide policies rarely makes sense.

The Fast Way: selinux-explain

One day, it just became too much — reading through audit.log by hand, hunting down the right restorecon or boolean tweaks for messed-up labels. Tools such as setroubleshoot help, true, yet they bring along Python processes and D-Bus connections. My stripped-down, isolated systems do not run those.

A small program took shape: selinux-explain — crafted fully in Rust, running without internet. It works through your terminal, staying fast by design. Built to explain SELinux rules locally, it avoids external dependencies. No cloud needed, just direct responses from your machine.

Most times, people guess what went wrong — here, denied logs go straight in. Once inside, each refusal gets broken down, clear as speech anyone understands. A reason appears without jargon, showing exactly why access failed. From there, a precise instruction forms, tailored to resolve the issue safely.

Key Features

Single static binary: No external libraries required during operation. Runs independently of system-installed components. Entire program contained within a single output. Does not rely on additional software at execution time.
Offline by default: Works without internet access — ideal for protected networks where external connections are restricted.
Context-aware: Because it recognizes patterns, containers get the :Z flag automatically. Web services often require specific permissions — this adjusts them without extra steps. For instance, when a server needs network access, the system enables it through policy changes. Knowing typical setups helps avoid common roadblocks. Configuration follows real-world usage rather than rigid rules. Each decision builds on what the environment actually does.
Extensible: Powered by a community-driven rules.toml file.

Try it out

You can grab the pre-compiled binaries for your architecture on the GitHub Releases page.

When SELinux stops your app, skip typing setenforce 0. Instead, send the log through selinux-explain — watch how it decodes the message silently. Each error finds clarity without disabling security layers first.

Should you come across a rare scenario the tool fails to identify, consider submitting a pull request. Alternatively, apply the --report option to contribute toward growing its collection of rules.

I Published My First npm CLI Tool

Fri, 03 Apr 2026 12:28:31 +0000

Hey folks!

Let me tell you about create-scaffold-kit — what it does, and my experience shipping it for the first time.

Why does this exist?

Every new project I start begins the same way:

ESLint. Prettier. Husky. Docker. CI.

An hour gone before I even write real code.

It’s tedious and honestly, it’s the same copy-paste every time.

So the question became, why not just automate this?

What is create-scaffold-kit?

It's a simple CLI tool that scaffolds a React or Next.js project with all the good stuff already set up. Just run one command:

npx create-scaffold-kit my-app

It asks you a few questions — framework, TypeScript, linting, testing, Docker, CI/CD and generates a full project ready to go.

Things it sets up for you:

✅ TypeScript (strict mode)
✅ ESLint with flat config (strict or standard)
✅ Prettier / OXfmt formatting
✅ Husky + lint-staged git hooks
✅ Vitest + React Testing Library
✅ Tailwind CSS
✅ Docker with multi-stage builds
✅ GitHub Actions CI/CD

No more copy-pasting configs. Just answer the prompts and start coding.

This is especially useful if you:

Start projects frequently
Care about consistent tooling
Don’t want to reinvent setup every time

Things I Didn’t Know Before Building a CLI

Here are things that were genuinely surprising while going through the process of building a CLI package for the first time. Maybe it saves you some time!

1. The `bin` field in package.json is the magic

Always wondered how npx create-something just... works. Turns out it's this little thing:

"bin": {
  "create-scaffold-kit": "dist/index.js"
}

That maps the command name to your entry file. Simple, but easy to miss.

2. Your entry file needs a shebang line

The first line of your CLI entry file must be:

#!/usr/bin/env node

Without it, the command just won't run. With tsup, this can be injected cleanly via the banner option in the config, no manual step needed:

banner: {
  js: '#!/usr/bin/env node',
}

3. Bundling for CLI is different

tsup handles the TypeScript compilation. But a few things stood out:

Setting "type": "module" in package.json
Making sure import paths use .js extensions, even in TypeScript source files
The files field to control what actually gets published to npm

4. The `files` field matters a lot

You can control which files get included when running npm publish:

"files": ["dist"]

Without this, you'd accidentally publish test files, source maps, scripts, everything. Not great.

5. `prepack` and `postpack` scripts are a thing

There are prepack/postpack lifecycle hooks that run before and after packaging. These weren’t on my radar before this project. Turns out they’re really handy for automating pre-publish steps.

6. Testing a CLI is... interesting

Vitest handles the unit tests here. Testing something that writes to disk and executes shell commands is tricky. Mocking fs, child processes, and prompts is a different kind of challenge compared to typical frontend component tests.

7. Publishing is both easy and scary at the same time

npm publish. Just two words. But right before running it:

"Was everything tested?"
"Is the version right?"
"Is the dist clean?"

A prepublishOnly script that runs type checking, linting, tests, and build before every publish is a lifesaver. It catches things before they go out.

Final Thoughts

This isn’t a groundbreaking tool, but building it gave me a much deeper understanding of the Node.js ecosystem, npm publishing, and how CLI tools actually work under the hood.

If you're a frontend dev who has never shipped a CLI tool — try it once. Even something small. The learning is worth it.

And if you give create-scaffold-kit a try, I'd love to hear your thoughts! It’s still early, but it works and is actively evolving..

Try it out

npx create-scaffold-kit my-app

Check out the GitHub

Thanks for reading!

How to Create a CLI Tool Using Bash: A Practical Guide for Developers

Wed, 18 Mar 2026 14:26:07 +0000

Command line tools are the backbone of productivity for developers, system administrators, and DevOps engineers. From automating repetitive tasks to managing servers efficiently, a well built CLI tool can save hours of manual work.

If you’ve ever wanted to build your own CLI tool using Bash, this guide will walk you through the process step by step. By the end of this article, you’ll understand how to create a functional, reusable, and user friendly command line tool that you can use in real world projects.

Whether you're working on Linux automation, DevOps workflows, or personal productivity tools, this tutorial is designed to help you level up.

Why Build a CLI Tool with Bash?

Before diving into the code, let’s understand why Bash is still a powerful choice for CLI tools.

1. Native to Most Systems

Bash comes pre installed on most Unix based systems, including Linux and macOS. This makes your CLI tool portable and easy to distribute.

2. Perfect for Automation

Bash excels at:

File manipulation
Process management
System monitoring
Task automation

3. Lightweight and Fast

Unlike heavier programming environments, Bash scripts are quick to write and execute with minimal setup.

What You’ll Build

In this tutorial, we’ll create a simple CLI tool called:

devtool

This tool will:

Accept command line arguments
Support multiple commands (like greet, cleanup)
Provide a help menu
Handle errors gracefully

Step 1: Create Your Script File

Start by creating a new Bash script:

touch devtool.sh
chmod +x devtool.sh

Add the shebang at the top:

#!/bin/bash

This tells the system to execute the script using Bash.

Step 2: Add a Basic Structure

A good CLI tool follows a clear structure.

#!/bin/bash

# Tool Name: devtool
# Description: A simple CLI tool for automation tasks

show_help() {
    echo "Usage: devtool [command]"
    echo ""
    echo "Commands:"
    echo "  greet        Print a greeting message"
    echo "  cleanup      Remove temporary files"
    echo "  help         Show this help message"
}

This creates a help function, which is essential for usability and self documentation.

Step 3: Handle Commands

Now let’s process user input using a case statement.

COMMAND=$1

case $COMMAND in
    greet)
        echo "Hello, welcome to devtool!"
        ;;
    cleanup)
        echo "Cleaning up temporary files..."
        rm -rf /tmp/*
        echo "Cleanup completed."
        ;;
    help|--help|-h)
        show_help
        ;;
    *)
        echo "Unknown command: $COMMAND"
        show_help
        ;;
esac

Why this matters

case makes your CLI tool clean and scalable
Easy to add new commands later
Improves readability compared to multiple if statements

Step 4: Accept Arguments

Let’s make the greet command more dynamic by accepting a name.

greet_user() {
    NAME=$1

    if [ -z "$NAME" ]; then
        echo "Please provide a name."
        exit 1
    fi

    echo "Hello, $NAME! Welcome to devtool."
}

Update your case block:

greet)
    greet_user $2
    ;;

Now you can run:

./devtool.sh greet Gift

Step 5: Improve Error Handling

A professional CLI tool should handle errors gracefully.

Example:

if [ $# -eq 0 ]; then
    echo "No command provided."
    show_help
    exit 1
fi

This ensures users always know what went wrong.

Step 6: Make It Globally Accessible

To use your CLI tool anywhere, move it into a directory in your system’s PATH.

mv devtool.sh /usr/local/bin/devtool

Now you can run:

devtool greet Gift

from anywhere on your system.

Step 7: Add Colors for Better UX (Optional)

Make your CLI tool more engaging with colored output.

GREEN='\033[0;32m'
NC='\033[0m'

echo -e "${GREEN}Operation successful!${NC}"

This improves readability, especially for logs and feedback messages.

Step 8: Organize Like a Real Tool

As your CLI tool grows, structure it properly:

devtool/
├── devtool.sh
├── commands/
│   ├── greet.sh
│   └── cleanup.sh
└── utils/

This makes your project:

Scalable
Maintainable
Easier to collaborate on

Real World Use Cases for Bash CLI Tools

You can extend your CLI tool to handle real world tasks like:

Deploying applications
Monitoring server health
Automating backups
Managing Docker containers
Running cron jobs

For developers working with Linux, VPS hosting, or DevOps pipelines, Bash CLI tools are incredibly valuable.

Best Practices for Building Bash CLI Tools

To ensure your tool is professional and reliable:

Use meaningful function and variable names
Always include a help command
Validate user input
Avoid hardcoding sensitive values
Log important actions
Keep scripts modular

Final Thoughts

Creating a CLI tool using Bash is one of the fastest ways to improve your productivity as a developer. With just a few lines of code, you can automate tasks, simplify workflows, and build tools tailored to your needs.

The beauty of Bash lies in its simplicity. You don’t need complex frameworks or heavy dependencies, just a clear idea and good structure.

Start small, keep improving, and before long, you’ll have a collection of powerful CLI tools that make your development process faster and more efficient.

If you found this guide helpful, share it with fellow developers and explore more tutorials on Bash scripting, DevOps, and automation. The more you build, the better you get.

I built a tiny Linux tool that shouts “FAHH” when I type the wrong command

Mon, 16 Mar 2026 11:25:23 +0000

I built a tiny Linux tool that shouts “FAHH” when I type the wrong command

A few weeks ago I noticed something about the way I work in the terminal.

When I’m focused and typing commands fast, I tend to make a lot of small mistakes.

Wrong command.
Misspelled command.
Sometimes I just type something that doesn't exist.

And the terminal just replies with the usual:

command not found

That message is… boring.

And also very easy to ignore.

So I started thinking:

What if the terminal could actually react when I type something wrong?

Not visually.
Not with an error popup.

But with sound.

Something dramatic.

Something like:

FAHH.

The idea

I wanted something very simple:

Whenever I type a command that doesn't exist in the terminal, play a sound.

Nothing fancy.
Just a tiny reaction that reminds me:

"Hey… that command doesn't exist."

I initially looked for something like this inside VSCode extensions.

There were some interesting ones, but they only worked inside the editor terminal.

I wanted something that works everywhere:

WSL
Debian
normal Linux terminals
zsh
bash

Basically anything I run in the shell.

So I decided to build a tiny CLI tool for it.

The result

I ended up creating a small tool called:

fahhctl

What it does is very simple.

When you type a command that doesn't exist:

fakecommand

You still see the normal error message:

command not found: fakecommand

But you also hear:

FAHH

How it works

The tool installs a small hook into your shell configuration.

When the shell detects a command that doesn't exist, it simply runs:

fahhctl play

Which plays a sound file.

That’s it.

No background process.
No daemon.
Just a tiny hook and a sound.

Installation

If you're curious and want to try it:

curl -fsSL https://raw.githubusercontent.com/hamza-topo/fahhctl/main/install.sh | bash

Then reload your shell:

source ~/.zshrc

Now try typing something wrong.

Customize the sound

The default sound is a dramatic FAHH, but you can replace it with anything.

The sound file lives here:

~/.local/share/fahh/fahh.mp3

So you can replace it with:

a meme sound
a warning beep
a voice saying "wrong command"
whatever you want

Why I actually like this

It sounds silly, but it’s surprisingly useful.

The sound acts like a tiny feedback loop.

Instead of silently ignoring mistakes, the terminal gives a quick reaction.

It helps me stay a bit more focused when I’m typing commands fast.

Also… it's just fun.

The project

If you're curious about the code or want to try it:

https://github.com/hamza-topo/fahhctl

It's a very small project, but it was fun to build.

And sometimes the smallest tools are the most satisfying ones.

Autopilot - Ctrl: AI Content Auditing with GitHub Copilot CLI

Wed, 25 Feb 2026 07:01:27 +0000

What I Built

autopilot-ctrl is a command-line tool that audits AI-generated social media content before publishing. Think of it as a "quality gate" for your content pipeline.

The Problem

My blog has an autopilot system that automatically generates posts for Twitter, LinkedIn, and Newsletter every time I publish an article. It works great... most of the time. But sometimes the AI produces:

Generic tweets without hooks
LinkedIn posts without proper structure
Newsletter intros that reveal too much (or too little)

I needed a way to evaluate quality BEFORE publishing and, if something doesn't pass, improve it automatically.

The Solution

autopilot-ctrl uses GitHub Copilot CLI to:

Audit content against platform-specific criteria
Assign a quality score (0-10)
Identify specific issues
Generate improved versions of failing content

                                 Audit Results                                
┌─────────────┬─────────┬───────────┬─────────────────────────────────────────┐
│ Platform    │  Score  │  Status   │ Issues                                  │
├─────────────┼─────────┼───────────┼─────────────────────────────────────────┤
│ Twitter     │ 3.0/10  │ [XX] FAIL │ No hook, missing hashtags               │
│ Linkedin    │ 7.0/10  │ [OK] PASS │ -                                       │
│ Newsletter  │ 8.0/10  │ [OK] PASS │ -                                       │
└─────────────┴─────────┴───────────┴─────────────────────────────────────────┘

Demo

Available commands:

# Check that Copilot CLI is installed
python -m ctrl check

# Audit content
python -m ctrl audit content.json

# Fix failing content
python -m ctrl fix content.json --apply

Screenshots of the flow:

Source code: github.com/Dalaez/datalaria/autopilot/ctrl

My Experience with GitHub Copilot CLI

How I Used Copilot CLI

The magic of autopilot-ctrl lies in how it integrates Copilot CLI in non-interactive mode:

# auditor.py
result = subprocess.run(
    ['copilot', '-s', '--no-ask-user', '-p', prompt],
    capture_output=True,
    text=True,
    timeout=60,
    encoding='utf-8'
)

Each audit sends a structured prompt to Copilot CLI and parses the natural language response to extract:

Numeric score (e.g., "Rating: 7/10")
List of issues (e.g., "No engagement", "Generic hook")
Improvement suggestions

What I Learned

Flag order matters: -p MUST be the last argument
Simple prompts work better: Long, structured prompts in non-interactive mode return empty responses
Copilot responds in natural language: I had to create flexible parsers to extract data from responses like "Rating: 7/10"

⚡ The Impact on My Workflow

Before autopilot-ctrl, I manually reviewed every generated post. Now:

git push → Autopilot generates content
python -m ctrl audit generated_content.json → Copilot evaluates
If something fails → python -m ctrl fix generates improvements
Approved content → Gets published automatically

Time saved: ~15 minutes per publication.

️ Tech Stack

Python + Click: CLI framework
Rich: Terminal UI with tables and colors
GitHub Copilot CLI: AI evaluation engine
YAML configs: Customizable prompts per platform

Conclusion

autopilot-ctrl demonstrates that GitHub Copilot CLI isn't just for generating code. It's a powerful tool for integrating AI into any pipeline - in this case, content quality evaluation.

If you have a system that generates content automatically, consider adding a "quality gate" with Copilot CLI. Your audience (and your engagement metrics) will thank you.

Questions? Drop them in the comments

This post is part of the Autopilot Project series, where I document how I automate content creation and publishing using AI.

I built a CLI for the process/port commands I could never remember

Mon, 09 Feb 2026 23:04:35 +0000

If you're like me and you google `lsof -i :3000 or ps aux | grep node | grep -v grep | awk '{print $2}'` at least once a month, I built something for you.

# What's on port 3000?
proc on :3000

# Kill it
proc kill :3000

# What ports is node using?
proc on node

# What processes are running in current directory?
proc in .

# Find node processes in current directory
proc by node --in .

# What's running this script?
proc for ./server.py

# Kill multiple things at once
proc kill :3000,:8080,node

Same syntax everywhere: :port, PID, or name.

Install

# macOS
brew install yazeed/proc/proc

# Windows
scoop bucket add proc https://github.com/yazeed/scoop-bucket-proc && scoop install proc

# Rust
cargo install proc-cli

# npm
npm install -g proc-cli

# Nix
nix profile install github:yazeed/proc

# Or just curl it
curl -fsSL https://raw.githubusercontent.com/yazeed/proc/main/install.sh | bash

How GitHub Copilot Helped Me Roast Its Own Users

Sun, 08 Feb 2026 07:19:53 +0000

What if GitHub Copilot didn’t just help you write code but judged you for it?

What I Built

I had been waiting for a challenge that truly sounded like me for a long time, and that’s when the GitHub Copilot CLI Challenge showed up.

Within five minutes, the idea that popped into my head was to use Copilot CLI to do something with Copilot itself.

That’s when the idea of roasting the user for their GitHub Copilot usage came up.

Then I started wondering how to implement it.

Whether to build something that runs in the terminal but that would consume RAM.

Should I try a different approach?

That’s when the idea of a VS Code extension popped up (GitHub CLI actually helped me there ).

This was my first time using an AI pair programmer to help me build a project completely, because I had never built, or even thought about creating a VS Code extension before.

The roasts are static for now and don’t use AI, because I couldn’t afford an API key .

Demo

Click the following link:
Copilot Roaster Extension

Install the extension using the link.

And your setup is complete.

Then, open any sample file to test it.

Ask GitHub Copilot to write something and accept its suggestion to see the magic ✨

Find my demo below:

Demo

You can find the GitHub repository here.

Feel free to fork, modify, and upgrade it.

My Experience with GitHub Copilot CLI

This was my first time using an AI pair programmer in the CLI. I was really excited to see how it worked. After installing it and typing copilot in the terminal, it felt like magic when this showed up.

I started wondering how it would work, which subscription it would use and which profile it would be linked to.

While thinking about all this, I typed a prompt, and that’s when I got an error saying I needed to log in to proceed further.

First, we need to use /login to sign in with our GitHub account.

After that, everything was smooth. The suggestions were almost exactly what I expected (maybe my prompt was too good ).

Then I tweaked things a bit, and tadaaa

The extension was ready and looked cool.

I added a few more roasts just to make sure the same ones didn’t repeat.

Then I published it on the Marketplace.

GitHub Copilot CLI provided me with the exact steps to publish the extension, because I had no clue how to do it and the whole process was smooth as well.

So go ahead, install the extension, let Copilot write your code, and brace yourself… because this time, you’re the one getting reviewed

Follow me on Linkedin | GitHub | Twitter

Subscribe to my newsletter and get articles delivered straight to your inbox.

BTOP++: The Resource Monitor I Didn’t Know I Needed

Sun, 04 Jan 2026 01:15:44 +0000

BTOP++: The Resource Monitor I Didn’t Know I Needed

Introduction

The year has just begun, the holidays are over, and it’s time to get back to building things.

There’s been a lot of talk about 2026 being “the year of Linux” — Steam even kicked off the year with promotional material hinting at that idea. Whether that prediction will come true or not, I can confidently say one thing: 2025 was the year of Linux for me.

After years using Linux sporadically, things changed when I decided to study it more seriously. Since then, the penguin has fully taken over my workflow — much to my family’s amusement.

With that context set, this article has a simple goal:

Wish everyone a productive new year
And introduce a tool I genuinely didn’t know I needed: BTOP++

Why Resource Monitoring Still Matters

Even with modern hardware, understanding how your system behaves in real time is still critical.

Whether you’re:

Running local development environments
Debugging performance issues
Working with containers
Or simply trying to understand where your resources are going

A good resource monitor gives you immediate feedback and helps you build intuition about your system.

That’s where terminal-based tools really shine.

HTOP vs BTOP++

Before anything else, it’s important to say this clearly:

HTOP is an excellent tool.

Created by Hisham Muhammad, HTOP is:

Fast
Minimal
Battle-tested
Hugely respected by the Linux community

It’s not by accident that it became a standard and even part of hacker culture.

So why look at BTOP++ at all?

What Makes BTOP++ Different

BTOP++ can be seen as a natural evolution of the HTOP idea.

While HTOP is written in C, BTOP++ is written in C++, which allows it to offer:

Richer visual components
Integrated CPU, memory, disk, and network graphs
A more modern and polished interface
Multiple panels without sacrificing usability

All of this still runs inside the terminal, with no significant performance penalty on modern systems.

Should You Switch?

As with most things in technology, there is no silver bullet.

Both tools excel in different scenarios:

HTOP

Minimal and extremely fast
Proven stability over many years
Ideal for SSH sessions and servers
Excellent choice for low-resource environments

BTOP++

Visually rich and modern
Excellent for desktops and workstations
Great for local development and debugging
Makes performance patterns easier to spot at a glance

A simple rule of thumb:

HTOP for servers. BTOP++ for desktops and workstations.

Installation

Arch / Manjaro / Big Linux

sudo pacman -Syu
sudo pacman -S btop

Run it with:

btop

Ubuntu 22.10 or newer

sudo apt update
sudo apt install btop

Ubuntu 22.04 LTS or older

sudo snap install btop

Useful Keyboard Shortcuts

Once inside BTOP++:

ESC or M → Open menu
↑ / ↓ → Navigate processes
F → Filter processes by name
K → Kill selected process

You can find the full list under Help in the menu.

Conclusion

BTOP++ isn’t a replacement for HTOP — it’s a complement.

HTOP remains the gold standard for minimal, reliable monitoring in server environments. BTOP++, on the other hand, brings clarity and visual insight that make it especially valuable on desktops and developer workstations.

If you spend a lot of time working locally on Linux, BTOP++ is absolutely worth adding to your toolbox.

Here’s to a productive year — and long live Linux

Merry Christmas… in Your Linux Terminal

Thu, 25 Dec 2025 21:06:45 +0000

And a Gentle Introduction to the Python CLI Ecosystem

Introduction

Today is Christmas — and if you’re reading this, I hope you’re doing well.

After a long year, our minds often try to create a false sense of urgency. Sometimes, the best thing we can do is pause, breathe, and say:
“Not now.”

With that in mind, this article brings a simple, fun, and educational tutorial, perfect for the holiday season.

The goal is straightforward:
run a Christmas tree animation directly in your Linux terminal.

Yes — Linux developers would rather write 100+ lines of code than decorate a real tree.
And we deeply respect that.

What Are We Building?

We’ll run a Python-based CLI called christmastree, using a tool called pipx.

Along the way, you’ll learn:

What pipx is and why it matters
How to run Python CLI tools safely and in isolation
How to run christmastree on:
- most Linux distributions
- Big Linux / Manjaro (alternative setup)

What Is `pipx`?

pipx is a tool designed to install and run Python applications in isolated environments, without affecting:

the system Python
other projects
existing virtual environments

Each application gets its own virtual environment, but remains accessible globally through your PATH.

Examples of CLI Tools Installed with `pipx`

Popular examples include:

black — code formatter
poetry — dependency manager
httpie — terminal HTTP client
christmastree — your animated Christmas tree

Installation (Official Method — Works on Most Distros)

Step 1: Install `pipx`

pip install pipx
pipx ensurepath

You may need to open a new terminal afterward.

Step 2: Clone the official repository

git clone https://github.com/MEHighKing/christmastree.git
cd christmastree
pipx install .

Step 3: Run it

christmastree

Alternative Setup — Big Linux (Manjaro)

Big Linux is a Brazilian distribution based on Manjaro, so the only difference is how pipx is installed.

Install `pipx` via pacman

sudo pacman -S python-pipx

Then follow the same steps:

git clone https://github.com/MEHighKing/christmastree.git
cd christmastree
pipx install .

Common Issue: Terminal Size

If you see this error:

Please enlarge your terminal to at least 100x40 (current: 85x34).
[exit=1]

Just resize your terminal window.

Check current size with:

tput cols; tput lines

Once it reaches 100x40 or more, run:

christmastree

Important Note ⚠️

Some tutorials suggest running:

curl -L https://raw.githubusercontent.com/MEHighKing/christmastree/master/christmastree.sh | bash

This does not work.
There is no shell script in the repository. The correct approach is using pipx.

Conclusion

I hope everything ran smoothly

If you enjoyed it, consider visiting the official repository and leaving a ⭐ — those developers are powered by coffee and code ☕

Official repository:
https://github.com/MEHighKing/christmastree

Merry Christmas — and long live Linux!

CodeContext

Thu, 25 Dec 2025 08:00:37 +0000

CodeContext is an innovative open-source project designed to facilitate faster developer onboarding by intelligently analyzing codebases.

Why CodeContext?

Onboarding new developers can often take between 1 to 3 months, during which they struggle with various challenges such as:

Searching for initial tasks or reference points
Understanding file dependencies and relationships
Navigating outdated documentation
Handling repetitive questions from team members

The Solution

CodeContext offers a solution by quickly analyzing a codebase and providing essential insights to enhance the onboarding experience:

Interactive Dependency Maps: Visualize the entire structure of the codebase with zoomable, force-directed graphs.
Knowledge Hotspots: Leverage a PageRank algorithm to identify critically important files within the project.
Personalized Learning Paths: Generate suggested reading orders to guide new developers effectively through the codebase.
Smart Contextual Information: Gain insights into Git history, authorship, and frequency of changes for each file.

These features collectively reduce the onboarding time significantly, converting the period from 3 months to just 3 weeks.

Features

Feature	Description
Interactive Dependency Maps	Visual representation of file relationships through dynamic graphs.
Knowledge Hotspots	Discover critical files based on their importance in the project using PageRank.
Learning Paths	Provides a topologically sorted order to help new team members navigate the project with ease.
Git Integration	Access detailed Git history and statistics for better context.
Team Contribution Map	Identify knowledge silos and assess risks related to team member dependencies.
Multi-Language Support	Currently supports Java and Kotlin, with plans for more languages.
Fast Performance	Built with parallel parsing and intelligent caching for efficiency.
Visual Reports	Generates clean HTML reports enhanced with D3.js visualizations.

Demo

An interactive demo illustrates the functionality of CodeContext by showcasing a dependency graph, knowledge hotspots, and learning path generation. To see CodeContext in action, run the command:

./gradlew run --args="analyze ."

Documentation

Comprehensive documentation is available to help users understand the architecture, development guidelines, API references, and more:

Contributing

Contributions are encouraged and can take many forms, including bug fixes, feature additions, or documentation improvements. A structured guide is provided to help newcomers get started. To explore open issues suitable for new contributors, browse the issues labeled good first issue.

Roadmap

Future enhancements include support for additional programming languages, integration of popular IDE plugins, and potential cloud-hosted services to extend functionality.

For those interested in optimizing their development processes and enhancing team efficiency, CodeContext provides essential tools and insights to streamline the onboarding experience. Visit the project's website for further information and resources.

Send emails from the terminal using pop

Mon, 22 Dec 2025 07:27:15 +0000

Multi-Account Email Sender (pop wrapper)

This script wraps Charm's pop to send emails from multiple accounts directly from your terminal without config edits. Select your email, then use pop's interactive UI or CLI flags.

Features

Switch between multiple SMTP accounts via gum (or fallback menu)
Secure secrets from ~/.zsh_secrets
Exports POP_SMTP_USERNAME, POP_SMTP_PASSWORD, POP_FROM automatically
Passes all pop args through
Shellcheck clean, bash-compatible

Environment Variables

In ~/.zshrc (non-sensitive):

export POP_SMTP_HOST="smtp.gmail.com" # or smtp.outlook.com, etc.
export POP_SMTP_PORT=587

In ~/.zsh_secrets (chmod 600, gitignore!):

export POP_SMTP_USERNAME1="*Emails are not allowed*"
export POP_SMTP_PASSWORD1="abcd efgh ijkl mnop" # Gmail/Outlook APP PASSWORD
export POP_SMTP_USERNAME2="*Emails are not allowed*"
export POP_SMTP_PASSWORD2="ijkl mnop qrst uvwx" # APP PASSWORD (16 chars, no spaces)

⚠️ POP_SMTP_PASSWORDs are app-specific passwords (not your regular login)—generate from Gmail/Outlook 2FA security settings.

Dependencies

pop (Charm)
gum (optional, menu fallback built-in)

Usage

chmod +x ~/.local/bin/send_email
send_email # Interactive pop
send_email --to *Emails are not allowed* --subject "Hi" --body "Test"

Here is the link to the gist https://gist.github.com/Vaishnav-Sabari-Girish/51cbfc493fee25c209c39f0e74a17103

Save your dotfiles workflow!

UserScanner

Mon, 01 Dec 2025 14:19:20 +0000

User Scanner

Repo: https://github.com/kaifcodec/user-scanner

Scan a username across multiple social, developer, and creator platforms to see if it’s available.
Perfect for finding a unique username across GitHub, Twitter, Reddit, Instagram, and more, all in one command.

Features

✅ Check usernames across social networks, developer platforms, and creator communities.
✅ Clear Available / Taken / Error output for each platform.
✅ Fully modular: add new platform modules easily.
✅ Command-line interface ready: works directly after pip install.
✅ Can be used as username OSINT tool.
✅ Very low and lightweight dependencies, can be run on any machine.

Installation

pip install user-scanner

Usage

Scan a username across all platforms:

user-scanner -u <username>

Optionally, scan a specific category or single module:

user-scanner -u <username> -c dev
user-scanner -l # Lists all available modules
user-scanner -u <username> -m github

Contributing:

Modules are organized by category:


user_scanner/
├── dev/        # Developer platforms (GitHub, GitLab, etc.)
├── social/     # Social platforms (Twitter/X, Reddit, Instagram, etc.)
├── creator/    # Creator platforms (Hashnode, Dev.to, Medium, etc.)
├── community/  # Community platforms (forums, niche sites)
├── gaming/     # Gaming sites (chess.com, roblox, monkeytype etc.)
├── donation/   # Donation taking sites (buymeacoffe.com, similar...)

Module guidelines:

Each module must define a validate_<site>() function that takes a username and returns:
- 1 → Available
- 0 → Taken
- 2 → Error / Could not check
Use httpx for requests, colorama for colored output.
Optional: modules can define a CLI parser if they support custom arguments.

See CONTRIBUTING.md for examples.

Dependencies:

License

This project is licensed under the MIT License. See LICENSE for details.

Advent of Code Interactive

Mon, 01 Dec 2025 10:09:08 +0000

Advent of Code Interactive

This script provides an interactive experience using the aoc-cli too.

Dependencies

aoc-cli : https://github.com/scarvalhojr/aoc-cli
gum : https://github.com/charmbracelet/gum
glow : https://github.com/charmbracelet/glow

With this script you can

View problems (By selecting the days)
Download the problem and input
Submit answer
View calendar
View the leaderboard (Private)

Here is the link to my gist where I have pushed the script

Link : https://gist.github.com/Vaishnav-Sabari-Girish/bc213e8539e666dac74249f25a868dec

user-scanner

Sat, 22 Nov 2025 14:13:01 +0000

User Scanner

Github: https://github.com/kaifcodec/user-scanner

Features

✅ Check usernames across social networks, developer platforms, and creator communities.
✅ Clear Available / Taken / Error output for each platform.
✅ Fully modular: add new platform modules easily.
✅ Command-line interface ready: works directly after pip install.
✅ Can be used as username OSINT tool.
✅ Very low and lightweight dependencies, can be run on any machine.

Installation

pip install user-scanner

Usage

Scan a username across all platforms:

user-scanner -u <username>

Optionally, scan a specific category or single module:

user-scanner -u <username> -c dev
user-scanner -l # Lists all available modules
user-scanner -u <username> -m github

Example Output:

Note*: New modules are constantly getting added so this might have only limited, outdated output:

 Checking username: johndoe078

== DEV SITES ==
  [✔] Codeberg: Available
  [✔] Cratesio: Available
  [✔] Dockerhub: Available
  [✘] Github: Taken
  [✔] Gitlab: Available
  [✔] Launchpad: Available
  [✔] Npmjs: Available
  [✔] Replit: Available

== SOCIAL SITES ==
  [✔] Bluesky: Available
  [✔] Discord: Available
  [✘] Instagram: Taken
  [✔] Mastodon: Available
  [✔] Pinterest: Available
  [✘] Reddit: Taken
  [✔] Snapchat: Available
  [✔] Telegram: Available 
  [✘] Threads: Taken
  [✔] X (Twitter): Available
  [✔] Youtube: Available

== CREATOR SITES ==
  [✔] Devto: Available
  [✔] Hashnode: Available
  [✔] Kaggle: Available
  [✔] Medium: Available
  [✔] Patreon: Available

== COMMUNITY SITES ==
  [✔] Coderlegion: Available

== GAMING SITES ==
  [✔] Chess_com: Available
  [✔] Osu: Available
  [✔] Roblox: Available
  ...
  ...
  ...

Contributing:

Modules are organized by category:

user_scanner/
├── dev/        # Developer platforms (GitHub, GitLab, etc.)
├── social/     # Social platforms (Twitter/X, Reddit, Instagram, etc.)
├── creator/    # Creator platforms (Hashnode, Dev.to, Medium, etc.)
├── community/  # Community platforms (forums, niche sites)
├── gaming/     # Gaming sites (chess.com, roblox, monkeytype etc.)

Module guidelines:

Each module must define a validate_<site>() function that takes a username and returns:
- 1 → Available
- 0 → Taken
- 2 → Error / Could not check
Use httpx for requests, colorama for colored output.
Optional: modules can define a CLI parser if they support custom arguments.

Dependencies:

⚠️ `community/` and `gaming/` are small, looking for contributions

Ytconverter

Wed, 05 Nov 2025 18:36:26 +0000

I recently built a command-line YouTube downloader in Python called ytconverter. It’s designed to fetch videos directly from YouTube and convert them into formats like MP3 and MP4. The goal was to make a simple, functional tool without external GUIs or bloated software — just clean CLI efficiency.

Key features:

Download YouTube videos directly from CLI
Convert to various formats (MP3, MP4, multiple video downloads.)
Handles basic metadata
Easy to set up and use

If you're someone who likes working with CLI tools, or Python automation, this might be useful for you.

The project is open-source, so feel free to try it out, suggest improvements, or even contribute if you're interested.

Here’s the repo:

https://github.com/kaifcodec/ytconverter

Let me know what you think! Suggestions, critiques, or PRs are all welcome.

InstaScrape

Tue, 30 Sep 2025 14:14:14 +0000

InstaScrape — Async Instagram Comment Scraper

Scrape all parent comments from any Instagram Reel with automated login, async speed, real-time progress, and clean exports — no manual cookie copying required.

✨ Features

✅ Automated Login: cookie.json persistence with iat + expiry, no manual cookies needed.
Self-healing Auth: detects expired cookies mid-run, prompts relogin, resumes automatically.
⚡ Async Engine: powered by httpx.AsyncClient with requests-per-second throttling.
Progress Tracking: accurate percent and ETA from Instagram’s comment count.
Dual Exports: TXT and JSON files saved in timestamped folders.

Requirements

Python 3.9+
Dependencies:

pip install -r requirements.txt

️ Installation

git clone https://github.com/kaifcodec/InstaScrape
cd InstaScrape
pip install -r requirements.txt

▶️ Usage

python3 main.py

Enter the Instagram Reel URL (e.g., https://www.instagram.com/reel/SHORTCODE/).
Set Max requests per second (5-7 recommended). Adjust for stability.
On first run, provide username/password; cookie.json is created and reused until expiry.

Output

TXT: download_comments/txt/reel_comments_YYYYMMDD_HHMMSS.txt
JSON: download_comments/json/reel_comments_YYYYMMDD_HHMMSS.json

Example structure:

  "generated_at": 1700000000,
  "count": 123,
  "comments": [
    { "username": "user1", "text": "Nice!", "created_at": 1699999000 }

How it Works

Cookie Lifecycle: cookie.json stores iat and expiry; validated on startup & during requests.
Error Resilience: retries transient errors and refreshes cookies on 401/redirect-to-login.
Progress Accuracy: uses Instagram’s comment count to calculate percent & ETA.
Async Efficiency: httpx.AsyncClient with HTTP/2, keep-alive, and RPS limiter.

Repository url: https://github.com/kaifcodec/InstaScrape.git

Create Launcher CLI (npm Package)

Sun, 03 Aug 2025 08:17:14 +0000

“Why am I still copy pasting the same setup files again and again?”

If you’ve ever asked yourself this after starting yet another web project...

You’re not alone — I’ve been there too.

So I built something to make project bootstrapping painless.

️ Meet `create-launcher`

A zero-config CLI tool that lets you scaffold modern web projects instantly, with everything pre wired and ready to go.

Features at a Glance

✅ Interactive CLI with prompts
⚛️ Project templates:
- React (Vite)
- Next.js
- Eleventy (11ty)
- Vanilla JavaScript & TypeScript
Tailwind CSS integration (optional)
TypeScript support
Pick your favorite package manager (npm, yarn, pnpm)
ESLint pre-configured
⚡ Auto installs everything you need

Get Started in One Line

npx create-launcher

The CLI walks you through setup, just answer a few prompts, and boom
Your project is scaffolded and dependencies installed. No extra config.

See It In Action

⚡ Creating a React + TypeScript + Tailwind project in under 30 seconds

Why I Built This

As a dev who loves shipping fast, I kept hitting the same roadblocks every time I started a new project - boilerplate, repeated setup, switching between Vite and Next.js, etc.

Now, with create-launcher, I can:

Start a project in under 15 seconds
Have a consistent, clean folder structure
Focus on writing code, not configuration

Check It Out

NPM Package
GitHub Repo

Ideas for Future Versions

Templates On (Vue.js, Svelte, Angular etc.)
Git init + first commit
Prettier integration
Optional GitHub Actions CI setup
Custom template support

Feedback Welcome

I’d love to hear what you think.
Found a bug? Have a feature request? PRs are welcome, and stars always appreciated ⭐

Let’s make spinning up projects feel exciting again.

♂️ About the Author

I'm Pranav Verma, a passionate Full Stack Developer and tech enthusiast exploring the intersection of DevTools, AI, and modern web development. I love building tools that simplify developer workflows and enhance productivity.

Connect with me:

If you liked this project, don’t forget to ⭐ it on GitHub and share it with fellow devs!

And, if you want to contribute something helpful to the community, just read the CONTRIBUTING.md in GitHub repo and start helping others and yourselves.

Auto-generate Commit Messages with LLMs in Your Terminal

Thu, 10 Jul 2025 07:58:47 +0000

Original post: https://hankchiu.tw/writings/auto-generate-commit-messages-with-ll-ms-in-your-terminal/

Writing commit messages can be a drag. While IDEs like Cursor can automate this, what if you live in your terminal and want a fast, controllable way to generate conventional commits?

This guide is for you. It's as simple as piping git diff to a command-line LLM client to create well-formatted commit messages without leaving the terminal.

Quick Summary

Use a non-interactive LLM client: We need a tool that takes input from a pipe, sends it to the model, and prints the result to standard output.
Craft a system prompt: Instruct the LLM to generate a message in the Conventional Commits format.
Create a Git alias: Make the entire process accessible through a simple command like git ca.

The System Prompt

First, let's define our instructions for the LLM. This prompt ensures the output is consistently formatted as a Conventional Commit:

Write a commit message in the Conventional Commits format. Use the structure:
<type>(<optional scope>): <short description>

<optional body>

<optional footer>

Example types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
Optionally, include a body for more details in bullet points.
Optionally, in the footer, use BREAKING CHANGE: followed by a detailed explanation of the breaking change.

Just return the commit message, do not include any other text.

LLM Clients for the Terminal

Several command-line tools can handle this task. Here are a few examples of how to use them, piping your staged changes directly to the model.

LLM CLI

git diff --cached | llm -s '<your-system-prompt>'

Gemini CLI

git diff --cached | gemini -p '<your-system-prompt>'

aichat

git diff --cached | aichat --prompt '<your-system-prompt>'

Claude CLI

git diff --cached | claude -p '<your-system-prompt>'

Create a Git Alias

To make this truly seamless, add an alias to your .gitconfig. This example uses llm to commit all staged changes and then displays the latest log entry.

Place your full system prompt directly into the alias or save it to a file and reference it.

[alias]
  ca = "!(git commit -m \"$(git diff --cached | llm -s 'Write a commit message in the Conventional Commits format...')\" && git log --stat -1)"

Now, instead of git commit, simply run:

git ca

Your staged changes will be sent to the LLM, the generated message will be used for the commit, and you'll see the result instantly. It's a quick, powerful way to keep your workflow moving, all from the comfort of your terminal.

Meet Hippoo: The Lightning-Fast CLI Tool Every Dev Needs to Check NPM Package Sizes

Wed, 14 May 2025 23:27:57 +0000

Introducing Hippoo — a blazing-fast CLI tool that helps you analyze and compare npm package sizes before you install them. Built by James Akpan

“Don’t just install it. Inspect it.”
— Hippoo’s unspoken philosophy

In the age of bloated bundles and performance-first web apps, Hippoo steps in like a digital bodyguard. — Hippoo is a smart, sleek CLI tool that helps you check and compare npm package sizes before they enter your codebase.

No more surprises. No more blind installs.

What is Hippoo?

Hippoo (yes, with two o's) is a lightning-fast command-line tool to analyze and compare npm packages — giving you clear insights about:

Minified & Gzipped Size
Dependency Count
️ Download Time
Tree-shaking Support
Hippoo Score (0–10)
Smart Recommendations

Hippoo answers the real dev questions:

Is this package too heavy?
Should I choose React or Angular?
Will this slow down my app?

Installation

You can install Hippoo globally using either npm or yarn:

# Using npm
npm install -g hippoo

# Using yarn
yarn global add hippoo

Basic Usage

Check a single package:

hippoo react@18.0.0

⚖️ Compare multiple packages:

hippoo compare react angular

✨ Sample Output (Real Example)

hippoo compare react angular

Metric	React	Angular
Size	7.4 kB	181.0 kB
Gzipped	2.8 kB	62.3 kB
Download Time	1ms	2ms
Dependencies	0	0
Tree-Shake	❌	❌
Hippoo Score	8/10	6/10

Best for Performance-Critical Apps: React
Best for Feature-Rich Projects: Angular

️ Command Reference

hippoo [package-name] [options]
hippoo compare [pkg1] [pkg2] [...]

Options:

-v, --version → Show version number
-d, --detailed → Show detailed breakdown
-j, --json → Output results in JSON
-h, --help → Show help info

Why Use Hippoo?

Size Analysis — Know what you're adding.
⚖️ Package Comparison — Pick the better tool.
Performance Insights — Stay light and fast.
Smart Recommendations — Use the right tool for the task/project.

Resources

Official Website
GitHub Repository
MIT License

Final Thoughts

Hippoo isn’t just a tool.
It’s a mindset — inspect before install.
Analyze before adding. Optimize before bloating.
Big ups to @codiejay (James Akpan) for building something every dev can use. Let’s support, test, and spread the word.

Next time you go to install a package, pause and ask:

“Did I Hippoo it first?”

Feel free to share thoughts, issues, or praise in the comments. And if you're vibing with Hippoo, don’t forget to ⭐ the repo!

How I Automated Git Commands Using Batch Scripting

Wed, 09 Apr 2025 19:04:19 +0000

In this article, I will show you how I automated Git commands using Batch Scripting on Windows.

As a developer, there are some Git commands that are very fundamental to my work. However, it gets tedious many times when you have to fire up your terminal, type in git commands, and then hit "Enter" on the keyboard for to run each command. Sometimes this process is repeated up to 10 times a day.

Therefore, I thought there must be a way to automate Git commands so that I do not have to manually type and run Git commands again.

I know, some might say why not just use Git desktop instead? Well, I love the terminal, and how it does not abstract my interaction with Git and Github.

So, I have written a Batch Script to automate my most used Git commands on my Windows machine and make my life a little easier. But first, what is Batch Scripting?

Batch Scripting Explained

Batch scripting refers to creating scripts (text files containing commands) for the Windows command prompt (cmd.exe) using the batch file language. These scripts have a .bat or .cmd file extension and automate repetitive tasks by executing a series of commands sequentially.

Key Characteristics of Batch Scripting:

File Extension: .bat or .cmd
Interpreter: Windows Command Processor (cmd.exe)
Purpose: Automates command sequences that would otherwise be typed manually
Syntax: Simple, line-by-line command execution with some programming constructs

Common Uses of Batch Scripting:

Automating file operations (copy, move, delete)
Installing software silently
System maintenance tasks
Launching programs in sequence
Simple system administration tasks

Advantages:

Easy to learn and use
No special tools required (just Notepad)
Built into all Windows systems
Quick for simple automation tasks

Limitations:

Limited programming features compared to PowerShell or Bash
No advanced error handling
Windows-specific (not cross-platform)

Now that we know what Batch Scripting is, let me show you how I used it to automate Git CLI on my Windows computer.

My most used Git commands are as follows:

git init
git remote add origin
git branch -M
git add .
git status
git commit -m
git push -u origin main

True, these are basic Git commands (and I use much more commands than these). However, because Batch Scripting runs sequentially, these are /the commands that typically follow one another when creating and pushing code/files to a Github repository; making them the easiest commands to automate.

That said, you can also write Batch Scripts to independently automate each Git command if you wish.

Batch Scripting Git Commands

Here is the Batch Script that I used to automate the above Git commands:

@echo off
:: Clear the screen
cls

set /p choice="Enter name of folder: "

:: Changes into the directory of interest
cd "%USERPROFILE%\Documents\%choice%"

:: Ask if the user wants to initialize Git
set /p git_init="Initialize Git? (yes/no): "
if /i "%git_init%"=="yes" (
    git init
)

:: Get the Git remote repository URL
set /p git_remote_url="Enter Git remote repo URL: "
if not "%git_remote_url%"=="" (
    git remote add origin "%git_remote_url%"
)

:: Get the branch name
set /p git_branch="Name of branch? "
if not "%git_branch%"=="" (
    git branch -M "%git_branch%"
)

:: Ask if the user wants to add files to staging
set /p git_add="Add to staging area? (yes/no): "
if /i "%git_add%"=="yes" (
    git add .
)

:: Get the commit message
set /p git_commit_message="Enter commit message: "
if not "%git_commit_message%"=="" (
    git commit -m "%git_commit_message%"
)

:: Ask if the user wants to push
set /p git_push="Push to branch '%git_branch%'? (yes/no): "
if /i "%git_push%"=="yes" (
    git push -u origin "%git_branch%"
)

:: Pause the script to view results
pause

The script begins by ensuring the terminal output is clean and easy to follow. It disables command echoing with @echo off and clears the screen using cls. This provides a tidy interface for the user.

Next, the script prompts the user to specify the name of a folder located in their Documents directory:

set /p choice="Enter name of folder: "
cd "%USERPROFILE%\Documents\%choice%"

This dynamic approach allows the script to work with any project folder the user specifies, without hardcoding paths.

Once inside the target directory, the script offers to initialize a Git repository. Using a simple yes/no prompt, the user can choose to run git init. The inclusion of /i in the condition makes the comparison case insensitive, accepting "yes", "YES", or "Yes" equally:

set /p git_init="Initialize Git? (yes/no): "
if /i "%git_init%"=="yes" (
    git init
)

Following initialization, the user is prompted to provide a remote repository URL. If a URL is supplied, the script adds it as the origin remote:

set /p git_remote_url="Enter Git remote repo URL: "
if not "%git_remote_url%"=="" (
    git remote add origin "%git_remote_url%"
)

The script then moves on to branch management. It asks the user to name their branch and, if provided, renames the current branch accordingly:

set /p git_branch="Name of branch? "
if not "%git_branch%"=="" (
    git branch -M "%git_branch%"
)

Then, it collects a commit message and, if one is entered, creates the initial commit:

set /p git_commit_message="Enter commit message: "
if not "%git_commit_message%"=="" (
    git commit -m "%git_commit_message%"
)

Finally, the script offers to push the changes to the remote repository. If the user agrees, it pushes the commits to the specified branch, setting the upstream branch for future pushes:

set /p git_push="Push to branch '%git_branch%'? (yes/no): "
if /i "%git_push%"=="yes" (
    git push -u origin "%git_branch%"
)

At the end of the script, pause keeps the terminal window open, giving the user a chance to review the output before closing.

In order to write your Batch Script, open any text editor on your computer like Notepad, write your Batch commands, and save it as a .BAT file.

To run the script, simply double-click on it.

To see the Git automation script in action, you can check out this GitHub repository.

You can also download and adapt other automation scripts in the repo for your use case. You can star and contribute to the repository, too :).

I hope this article has helped you get started with automating repetitive tasks on your computer. If yes, then please like and share with others it might benefit.

Here are other helpful resources to get you started with Batch Scripting:

https://www.seobility.net/en/wiki/Batch_Scripting

https://en.ryte.com/wiki/Batch_Programming/

https://www.tutorialspoint.com/batch_script/index.htm

https://exercism.org/tracks/batch

Coder Legion - Recent posts tagged cli

Terminal Agent vs. Web Chat: Pick by Blast Radius

I Built a C++ CLI That Hunts Down Secrets Hiding in Your Git History

What it does

Key features

Example output

Getting started

Why C++20

Try it out

Update - Sep 3:

Jev & computer-use

What is Jev?

On computer-use

Claims and things to look out for

FireMigrate: leave Firebase for Postgres without dumping everything into JSON

How OpenAI Codex let me down — and why I built Codey, an open-source coding assistant

Git Worktrees Are Underrated

The problem with branches

Worktrees

Why nobody uses them

A better workflow with arbor

What makes it stick

Where I use them most

Git worktree best practices

Try it

They Asked for My AI Rules. But I Could Not Just Hand Them Over.

The rules worked because I built them for one repo

The problem showed up the moment other people wanted in

I was solving the wrong problem the whole time

Nobody on a team agrees on one AI tool

What the tool had to actually do

I did not build everything I wanted to

Cava segfaulting inside WezTerm (Flatpak)? Diagnosis and fix in one command

⚡ TL;DR — Fix in two commands

🔍 What's happening under the hood

Why does WezTerm Flatpak cause the crash?

Confirming with GDB

✅ Step-by-step fix

1. Update your packages

2. Grant device access

3. Fully restart WezTerm

4. Test it

🖱️ Alternative: Flatseal

⚠️ If it still doesn't work

🔄 Last resort: native WezTerm

📌 Summary

rdev-go-ddgen: Automating Domain Directory Boilerplate for Go Applications

Your Codebase Is Too Big for an AI. Here's How to Give It Only What Matters

What it does

The part I'm most excited about

Other things it does

Honest limitations

Try it

I built a CLI that eliminates README reading forever

cover_image: https://rexrun.dev/logo.png

The problem

The solution: rex

How it works

Demo

All the verbs

Killer feature: rex clone

Monorepo support

Team workflow: rex init

.env loading

Why I built this

Technical details

Install

Links

I built an AI Agent that lives directly in your CLI and Desktop

I built an AI Agent that lives directly in your CLI and Desktop

What Mint can do

Unified AI CLI Agent

Desktop Assistant

MCP Support

Multi-Provider Support

Safety First

Why I built it

GitHub

Ditch the Clunky GUIs: Meet ComChan, the Blazingly Fast Rust Serial Monitor

What is ComChan?

1. The `bin` field in package.json is the magic

4. The `files` field matters a lot

5. `prepack` and `postpack` scripts are a thing