DEV Community: M N Mustakul Amin Talukdar

haunted-shell: a tiny local ghost that whispers about my shell commands

M N Mustakul Amin Talukdar — Thu, 29 Oct 2026 13:11:22 +0000

Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine Submission 👻

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 4.

What I Built

haunted-shell is a tiny ghost that possesses my terminal. A shell hook watches each command I run, and a small open-weight model on my own machine whispers back one short, eerie comment. It never touches the command itself - it only watches and whispers.

Real ghost output from the build's test runs. Each line below is a sample command string fed to the tool as text input (never executed), with an exit code passed alongside (2-core VM, model on CPU, no API key, no account):

$ git push origin main
👻 your code is spreading like a plague... across the night

$ rm -rf build/
👻 ridding yourself of the unwanted... but beware, there's no going back now

$ grep -r TODO .
👻 letting the shadows whisper through the files

$ sudo systemctl restart nginx   (sample string; exit code 1 passed as input)
👻 nginx's head is stuck in a wall, you need a wrench.

That last one is technically nonsense, but a 1.5B ghost doing its best is pretty much the Halloween brief.

This is the Halloween sibling of lazycommit, my Week 3 project. Same machine, same idea of a small local model doing one fun job, new costume.

The ghost needed a bigger brain

The first version used the exact same model as lazycommit: Qwen2.5-Coder 0.5B Instruct, about 400 MB. For commit messages it worked well in the Week 3 tests, where it picked the right Conventional Commit type on all three real commits. In the ghost test runs it just repeated the input back like a court stenographer:

$ git push origin main
👻 A mortal ran: `git push origin main`.

So the ghost moved into Qwen2.5 1.5B Instruct, about 1 GB, still tiny, still running on plain CPU, and the whispers started sounding like whispers.

The second fix reused a pattern from the Week 3 project: a small model follows a few concrete examples much better than a paragraph of instructions. My first prompt was rules only, and the model kept retelling the command instead of commenting on it. With four short example whispers in the prompt (one about ls, one about git commit, one about ping, one about mv), it imitated the format right away.

How it works

The pipeline is small on purpose:

A PROMPT_COMMAND hook captures the last command and its exit code after each command finishes.
It calls haunt whisper -- "$last_cmd" "$exit_code" in the background, detached. Your typing never waits for inference, and if anything fails the CLI exits silently with code 0. A lock file keeps it to one ghost at a time - if you type faster than it thinks, extra whispers are dropped instead of stacking up. A ghost must never break a shell.
Boring commands (ls, cd, pwd, ...) are skipped, and --every N throttles it to every Nth command so it stays funny instead of noisy.
Commands that look like they contain credentials (passwords, tokens, keys) are skipped entirely - the ghost never sees them.
The command is trimmed to 120 characters and sent, as data, with the ghost persona plus the four examples. Nothing is ever evaluated or executed - the ghost only reads.
The reply is squashed to one line and printed dim and italic with a 👻 prefix.

The CLI is plain Python with zero dependencies for the default backend. It talks to a local server that speaks the OpenAI chat API. Verified in testing: the HTTP backend against a mock server, and the in-process llama.cpp backend that produced every whisper quoted above. Ollama and LM Studio speak the same API and are expected to work, but are not verified yet. The endpoint is loopback-only by default and the client refuses to follow HTTP redirects, so a misconfigured local server cannot bounce your commands somewhere remote. A deliberate HAUNT_ALLOW_REMOTE=1 override exists for people who run the model on another machine of their own. There is also an optional in-process backend using llama-cpp-python if you do not want to run a server at all.

On a 2-core VM with the model on CPU, one whisper took about 2 to 5 seconds. That is one measured result on that VM, not a benchmark. The ghost runs detached, so you never sit waiting for a reply - but it does spend those few CPU-seconds per whisper in the background, so on a weak machine you will want --every N rather than a comment on everything.

The project has 17 pytest tests covering the prompt builder, the throttling, the fail-silent behavior, the secret filter, the loopback guard, redirect refusal, and the HTTP backend against a mock server. All pass. I also tested the hook in an isolated shell: it whispers on real commands, stays quiet for ls, preserves the exit code of a failed command, and disappears cleanly when you remove the line from your shell config.

Why open innovation matters here

Shell commands are some of the most sensitive text on a machine. They carry folder names, project names, hostnames, sometimes worse. A ghost that sends your command history to a cloud API is not a ghost, it is spyware with a Halloween costume.

Because the model is open-weight and runs on my own machine:

Private: with the default configuration, whispers are generated on loopback only and the tool never writes command text to disk. Your shell's own history behaves exactly as it always has - that part is unchanged by this tool. And to be clear about the limit: local processing is not secret-proof, which is why likely-credential commands are filtered out before the model ever sees them.
Offline after setup: installing the package and downloading the model need the internet, once. After that, whispers need no network at all. The tool itself needs no API key and no account.
Free: no per-token bill for a toy, no subscription.
Swappable: when the 0.5B coder model turned out to be a bad ghost in testing, I swapped in a 1.5B instruct model by changing one string. No vendor migration, no new SDK, no new pricing tier. The same OpenAI-compatible interface meant the whole tool kept working.

That swap is the open-ecosystem advantage in miniature: not just free as in money, but cheap to change your mind.

Code

Source code on GitHub: https://github.com/MRNOWSHIRWAN/haunted-shell

The application code is MIT licensed. The model weights keep their own Apache-2.0 license.

Setup, if you have Ollama:

pip install git+https://github.com/MRNOWSHIRWAN/haunted-shell.git
ollama pull qwen2.5:1.5b-instruct
haunt install-hook >> ~/.bashrc
exec $SHELL

Uninstall is deleting that one line from your ~/.bashrc.

Happy Halloween. Check your shell before you type 👻

lazycommit: a tiny local model writes my commit messages so I don't have to

M N Mustakul Amin Talukdar — Thu, 22 Oct 2026 04:23:58 +0000

Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady Submission 🦥

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 3.

What I Built

lazycommit is a small CLI that writes git commit messages for me. I stage my changes, run lazycommit, and a small open-weight model running on a server VM reads the diff and answers with one Conventional Commit message, like feat: add timeout option to portscan. With lazycommit --commit it commits right away.

I commit to GitHub every day. Writing the message is the part I always want to skip, and "fix stuff" as a message helps nobody. This is the laziest useful thing I could build: one command, and the boring part is done.

The whole tool is plain Python with zero dependencies. It talks to any local server that speaks the OpenAI chat API: Ollama, llama.cpp, LM Studio. The default model is Qwen2.5-Coder 0.5B Instruct, about 400 MB, which runs fine on a laptop CPU.

Demo

Here is a real run in a demo repository. I staged a change that adds a timeout option to a small port scanner:

$ lazycommit
lazycommit: 1 staged file(s): portscan.py
lazycommit: asking qwen2.5-coder:0.5b-instruct at http://127.0.0.1:18090/v1 ...
feat: add timeout option to portscan

Then two more real commits, fully written by the model:

$ git log --oneline
106f562 test: add test for localhost closed port
4595f1b docs: add README with project description
b8f5cf6 feat: add timeout option to portscan
0010f18 feat: basic tcp connect scanner

The model picked the right Conventional Commit type all three times: feat for the feature, docs for the README, test for the test file. Each message took about 2 seconds on a 2-core VM with the model on CPU. That is one measured result on that VM, not a benchmark.

Code

Source code on GitHub: https://github.com/MRNOWSHIRWAN/lazycommit

The application code is MIT licensed. The model weights keep their own Apache-2.0 license.

Setup takes two commands if you have Ollama:

pip install git+https://github.com/MRNOWSHIRWAN/lazycommit.git
ollama pull qwen2.5-coder:0.5b-instruct

Then lazycommit inside any git repo with staged changes.

How I Built It

The pipeline is small on purpose:

Read git diff --cached, staged changes only.
Trim very large diffs so a small model stays inside its context window, keeping every changed file's name visible.
Ask for one message with three tiny examples (a feat, a docs, a test diff). I found that a 0.5B model follows one concrete example much better than a paragraph of instructions. Without the docs example it called a README change a feat; with it, it gets the type right.
Clean the output: strip quotes, markdown fences, and "Commit message:" lead-ins, lowercase the summary. If nothing usable remains, it says so and asks you to write the message yourself. It never invents one.

The default mode only prints the suggestion. --commit is a separate, deliberate flag. There are 15 pytest tests covering the cleanup rules, the diff trimming, the HTTP client against a fake local server, and the full flow in a temporary git repository. All pass.

Why Open Innovation Matters

A commit message generator that sends your diff to a hosted API is a strange product. Your staged diff is exactly the code you have not published yet. With an open-weight model, the diff never leaves the machine: no account, no API key, no terms of service, no per-request cost. It works offline, on a train, and it will still work in five years because the weights sit on my disk.

Open weights also made the engineering honest. I could read the model card, check the license, download the exact file, and run it with an open-source server (llama.cpp). If a bigger model writes better messages tomorrow, I change one environment variable and keep everything else.

The tradeoff is real and I want to name it: a 0.5B model is not a genius. It gets the type and the subject right far more often than not, but I still read the message before I push. That is why the default mode only prints. Being lazy is the goal; being careless is not.

For me this was also a first real step from using AI through chat windows to running AI as a local component in my own tool, and that shift only happened because the model and the server are open.

DukaanDraft: a local AI writing helper for small shops

M N Mustakul Amin Talukdar — Sun, 18 Oct 2026 20:21:51 +0000

This is a submission for the DEV Hacktoberfest Week 2 Challenge.

What I Built

DukaanDraft is an English-only prototype that turns a local shop's short offer facts into an editable post draft.

The workflow is simple: enter a shop name and offer facts, generate a rewrite, compare it with the original facts, edit, and copy. Nothing is posted automatically. The destination labels help organize a draft for WhatsApp, Google Business Profile, or Instagram; they do not change the model prompt yet.

The side-hustle idea is a human-reviewed post-writing service for local shops. It is an idea to test, not an existing business. There are no customer, revenue, or willingness-to-pay claims.

Demo

The fictional test input was:

Shop: Fictional Store
Offer facts: rice for Rs 50 per kg.

The model returned:

Fictional Store sells Rice at Rs 50 per Kg.

The complete local browser-to-Node-to-model test returned this draft in 3.8 seconds on the test computer. This is one measured result, not a performance guarantee. First use also downloads model weights.

The interface keeps the original facts under the editable draft, alongside a warning to check every claim. A small model can still invent details or change a name. In other tests it added "affordable" or changed a shop name, which is why human review is part of the product rather than an afterthought.

Code

Source code on GitHub

The application code is MIT licensed. The model weights keep their own Apache-2.0 license.

To run locally with Node.js 20+:

npm install
npm start

Then open http://127.0.0.1:8787 on the same computer. The prototype was tested with Node 22 on Linux. It is not publicly deployed.

How I Built It

The app uses plain HTML and JavaScript for the form, a small Node HTTP server, and Transformers.js for local inference.

The AI core is SmolLM2-360M-Instruct, using the ONNX community conversion. The quantized model runs on the CPU in Node, not through a hosted inference API. No API key or new account is needed to run the app.

The server listens only on the local loopback address and accepts local same-origin browser requests. Model files are downloaded from Hugging Face; shop text is processed locally by this application. The first download is hundreds of MB, and model loading needs enough free memory. This is not a phone-only or low-memory-device promise.

I kept the scope small: English rewriting, an editable result, original facts for comparison, and an explicit copy action. Earlier API-hosted and browser-only inference approaches were explored but were not verified as working routes and are not the shipped version.

Why Does Open Innovation Matter

Open weights make it possible to test this idea without an inference-service account or a per-request API dependency. The model can be downloaded, inspected through its published documentation, and run locally. Open-source application code lets someone else change the workflow or replace the model without starting from scratch.

That freedom also makes the tradeoffs visible. A small local model is accessible, but it is not automatically accurate enough to write a shop's public claims. The useful next step is to test with real shop owners, measure factual errors, and find out whether a reviewed writing service saves them enough time to pay for it.

For now, DukaanDraft is a working local experiment with a clear review step, not a claim of a finished commercial product.