DEV Community: limack0

I stopped trusting curl | sh — so I built a tool that reads the script first

limack0 — Wed, 17 Jun 2026 00:44:01 +0000

Every developer has done it.
You hit a README, you see the install command:

curl -fsSL https://example.com/install.sh | sh

And you run it. Maybe you skim the script first. Maybe you don't. But you run it.
I've been doing this for years. And each time, a small voice in the back of my head says: you have no idea what that script actually does. You just piped a stranger's code straight into your shell.

Eventually I got tired of ignoring that voice.

What the pattern actually is

curl | sh is not a bad pattern — it's a fast, convenient pattern with a real trust gap. The script runs with your permissions, in your shell, right now. It can:

Install something with sudo
Delete files with rm -rf
Write to your disk with dd
Access your SSH keys or .env files
Set up a cron job or a systemd service that runs again next reboot
Decode and run a payload with base64 | eval Most install scripts do none of these things maliciously. But many do several of them legitimately — and you wouldn't know which ones until something went wrong. --- ## What I built instead I'm a solo founder based in Ouagadougou, Burkina Faso. I build with heavy AI pairing — I'm not a trained engineer, I work with Claude, review the output, and ship. This tool (peek) was AI-paired and reviewed by me before release. peek is a ~130-line POSIX shell script that sits in front of the pattern:

# Instead of:
curl -fsSL https://example.com/install.sh | sh
# Do:
peek https://example.com/install.sh

Before anything runs, peek:

Fetches the script
Scans it for risky patterns
Prints a risk score and the exact dangerous lines
Asks you to confirm — and refuses to auto-run a HIGH-RISK script unless you type RUN You can also pipe into it, or run it in analysis-only mode:

curl -fsSL https://example.com/install.sh | peek     # analyze from a pipe
peek --print ./downloaded.sh                          # never runs, analysis only

What it flags (and what it doesn't)

The patterns peek checks:

Root escalation — sudo, running as root
Destructive file ops — rm -rf, find -delete
Raw disk writes — dd of=/dev/sd, mkfs
Obfuscated payloads — eval, base64 -d | sh
Credential access — reads from ~/.ssh, .env, .aws
Persistence — writes to cron, systemctl enable, init scripts
Network calls — wget/curl inside the script (downloading more things)
Generic secret assignments — secret=, password=, token=, key= Each finding has a severity (CRITICAL / HIGH / MEDIUM / INFO). The final score gates the auto-run. --- ## The honest part: it's a heuristic, not a sandbox This is important and I want to say it plainly. peek can be fooled. If a script:
uses obfuscation peek doesn't recognise yet
downloads a second-stage payload after running
does something destructive through a helper binary it installs first ...peek won't catch it. A clean score does not mean a script is safe. It means nothing obvious matched. The real value isn't "this script is safe." The real value is: it makes you stop and look, and it surfaces the lines you'd otherwise skim past. For HIGH-RISK scripts, peek will refuse to auto-run and will page the full script so you can read it yourself. That's the intended workflow: peek narrows your attention to the suspicious parts, then you judge. I considered putting a disclaimer like "always read the full script before running" in the output. Then I realized: peek IS that disclaimer, in executable form. --- ## Yes, I see the irony The pack that contains peek has its own one-liner installer:

curl -fsSL get.limackcorp.online | sh

I see the irony. So: before you use peek to audit anyone else's scripts, read mine first.

`peek.sh` is ~130 lines of plain POSIX shell, no dependencies, no hidden calls. The repo is at https://github.com/limack0/limack-devtools — read it, then use peek to audit it if you want the recursive experience.

peek is part of a larger pack

I built 11 other tools in the same session, all single-file shell scripts, all targeting the same constraint: things that work when the infrastructure doesn't.
The ones most related to this post:

secrets-doctor — scans your files for leaked API keys, tokens, private keys. Local-only, nothing uploaded, exits non-zero in CI.
tunnelforge — exposes a local port via Cloudflare in one command. No ngrok account.
devbox — sets up a dev machine including an offline mode: prep all installers on a connected machine, deploy on an air-gapped one. Full pack: https://github.com/limack0/limack-devtools --- ## What I'd genuinely want feedback on The pattern list in peek.sh is where I'm least confident. Specifically:
False negatives — what risky patterns am I missing? (Particularly multi-stage obfuscation, environment hijacking, LD_PRELOAD tricks)
False positives — the generic secret=... rule is the noisiest. What good scripts would peek flag unfairly?
The scoring weights — is CRITICAL/HIGH/MEDIUM calibrated right, or should the thresholds shift? PRs very welcome. The whole point of an open-source script is that you can see exactly what it's doing — and improve it. --- All tools in this pack were AI-paired with Claude, reviewed and pushed by me.

I kept rewriting the same quiz + spaced-repetition code. So I packaged it into an API.

limack0 — Tue, 02 Jun 2026 16:49:24 +0000

While building my own medical edtech product, I wrote the same "text → quizzes + flashcards + review schedule" plumbing at least three times. Every new feature, same chore: call an LLM, parse the output, schedule the next review, and avoid paying twice for the same input.
So I cleaned it up into one small API — QuizForge:

POST /generate — text, a URL, or a PDF → MCQs, short questions, flashcards (in the language you ask).
POST /grade — score a free-text answer 0–5 with feedback.
POST /review/next — SM-2 spaced repetition, the next due date for a card. Two things I cared about:
Don't pay twice. Identical input is served from a content-hash cache — no second LLM call.
Make it testable. The LLM is injected, so the whole thing runs offline — 29 tests, no network. It's live as a hosted API with a free tier to try it, and there's a self-host version (Docker, bring your own LLM key) for people who'd rather run it themselves. Full disclosure: I build with AI assistance (I pair with Claude), and I'm a solo founder — a maxillofacial surgeon who got into shipping software, not a team. Support is email-only, but I answer everything. Happy to dig into the design — and I'd genuinely like to hear how you'd price the hosted version. Hosted (free tier): https://rapidapi.com/limack0/api/quizforge Self-host (source + Docker): https://limack.gumroad.com/l/quizforge

5 walls I hit shipping an AI reading app from West Africa (and what I'd tell past-me)

limack0 — Fri, 29 May 2026 21:32:58 +0000

I'm a maxillofacial surgeon in Ouagadougou, Burkina Faso — and a self-taught builder who's been coding since medical school. Over evenings and weekends, I shipped Readium — a production AI reading app that lets you discuss books with Claude while you read them, in any language. Built AI-paired with Claude, reviewed and deployed by me.
Most "I shipped an AI app" write-ups cover the happy path: clone a starter, glue an LLM, deploy to Vercel. The walls I hit weren't there. They were in the spaces between the libraries.
Here are five of them — and what I'd tell myself a few weeks ago.

Wall 1 — SSE streaming broke at the seam between the LLM and the browser

I assumed streaming "just worked" once OpenRouter returned a stream. It does — until your server-side handler, your reverse proxy, or your browser code introduces a buffer somewhere along the path.
The chain has at least three places where buffering can silently kill streaming:
The LLM API (fine on its own)
Your Node server-side handler (fine if you forward chunks instead of accumulating them)
The reverse proxy / CDN (often buffers entire responses by default)
The failure mode is always the same: the UI looks exactly like the LLM is slow. It isn't — somewhere between OpenRouter and the browser, bytes are being withheld until the connection closes, then dumped in one chunk.
What I'd tell past-me: streaming isn't a feature of the LLM, it's a property of your entire request path. If you can't watch tokens land character-by-character in curl -N against your origin, you don't have streaming, you have a slow non-stream pretending. Set Cache-Control: no-transform and X-Accel-Buffering: no headers from your handler, disable response buffering on every layer in front of it, and verify with curl -N before you trust the UI.

Wall 2 — fetch hangs forever on certain hosts (and the fix isn't where you think)

I had a proxy route that fetched from an external API. Worked locally. Worked in staging. Deployed to production: the route would hang for ~60 seconds, then time out. No errors. No logs. Just silence.
I spent two days blaming my code. Two days.
The bug was in undici, Node's built-in fetch implementation. When the remote host's DNS returns both IPv6 and IPv4 records, undici picks IPv6, opens a TCP connection, and waits. If the route between your container and that IPv6 address is broken (which it commonly is on VPS networks), there's no timeout — undici just sits there.
The fix is to bypass fetch and use the lower-level node:https with family: 4 to force IPv4:
import https from "node:https";
https.get(url, { family: 4, timeout: 10_000 }, (res) => {
// ...
});

What I'd tell past-me: when a network call hangs silently in production and works locally, suspect IPv6 before suspecting your code. This has been a real, undocumented production issue across the JS ecosystem since undici became the default in Node 18.

Wall 3 — The platform shows "Published" while functionally serving empty receipts

I had two products live on Gumroad. The dashboard showed them as published. I almost moved on to writing the launch post.
Ran one final API audit before announcing. The products were returning file_info: {}, covers: [], custom_receipt: "", and published: False under the hood. Zero files attached for any actual buyer. The dashboard UI had been showing "Published" while the underlying flag had silently flipped.
It turned out that every PUT against /v2/products/{id} that touched the description was wiping the uploaded files, the custom receipt template, and the published flag. There was no notification, no email, no warning. If a paying customer had bought during that window, they'd have paid $29 and downloaded literally nothing.
The fix took five minutes. The "how is this not in their docs" moment took a full weekend.
What I'd tell past-me: a product can pass every UI signal of being shippable while being functionally broken. Run an end-to-end check (API audit or self-buy) the day before any launch — and after any "harmless" edit you didn't realize was destructive.

Wall 4 — The cover said "80 pages" — but pandoc kept making it 83
I'd designed my ebook cover in SVG with "80 pages" as a visible design element. By the time the final build came out it was 83 pages — pandoc adds frontmatter, LaTeX adds a titlepage, both of which sneak in.
I tried to fudge the markdown to land back at 80 pages. I tried adjusting LaTeX margins. Three iterations later I was at 81, then 84, then 82. The cover had become a tax on every future rebuild.
The fix was a one-line edit on the SVG: I replaced "80 pages" with "field manual". The cover became stable across page-count drift. I updated marketing copy from "80 pages" to "83 pages" and moved on.
What I'd tell past-me: don't put fragile facts on your cover. The cover should compress your positioning, not commit you to a number that drifts every time you rebuild.

Wall 5 — I built the product, then realized I didn't know how to be found

The product was live for weeks before anyone outside my immediate network heard about it.
I'd separated "engineering" (safe, virtuous, what I knew) from "marketing" (cringe, salesy, what I didn't). So I kept shipping features and writing nothing public. The distribution half of the loop simply wasn't there.
This week, a non-technical founder on Indie Hackers gave me a reframe I haven't been able to forget. She wrote:
They're the same thing if the engineering is honest enough.
She meant the line I'd been drawing between "writing about my technical decisions" and "marketing my product" doesn't actually exist when the engineering is being written about truthfully. I'd been spending months treating them as separate tracks — calling one "documenting" (safe, virtuous) and the other "selling" (cringe). That false dichotomy was the thing keeping me silent.
This article is me testing the reframe in public.
What I'd tell past-me: you don't need to add a separate marketing track on top of engineering. You need to publish what you already know, honestly, where people who care end up reading.

What I'd actually do differently

If I could redo the past few weeks, I'd do exactly two things differently:
Write the public technical posts from week one, not at the end.
Self-buy my own product after every change to it — including the changes I think can't possibly break it.
Everything else, including the painful parts, was load-bearing.
I packaged what I learned into a field manual called "Building AI-Native Reading Apps" — 83 pages, 10 chapters covering OpenRouter streaming, the undici IPv4 fix, entity extraction, Gutenberg bulk ingestion, and the rest of the walls above in code-level detail. AI-paired with Claude, reviewed and verified by me. If you're shipping your own AI app and want this in one place: limack.gumroad.com/l/ai-reading-apps. Free Chapter 1 sample (the SSE streaming pipeline) is on the page before you