DEV Community: DevLog

Fixing npm Global Command Not Found on Windows

DevLog — Tue, 01 Sep 2026 05:43:14 +0000

Fixing npm Global Command Not Found on Windows

I recently hit a wall while configuring my development environment on Windows. It's one of those subtle issues that can waste an afternoon if you don't know what to look for. Here's exactly how I diagnosed and fixed a 'command not found' error after a successful global install.

The Problem
I decided to add a markdown processing tool to my toolkit by running:

npm install -g markdown-it-cli

The terminal output confirmed the installation succeeded, displaying a message about added packages. Satisfied, I tried to use it by typing markdown-it-cli in the command line. Windows immediately responded with: 'markdown-it-cli is not recognized as an internal or external command, operable program or batch file.'

This error means Windows looked through every folder in its search list and couldn't find an executable with that name.

Attempts and Failures
My initial reaction was to suspect the package itself might be broken. I tried running it using npx, which executes packages without requiring a global install:

npx markdown-it-cli -v

This worked instantly, printing the version number. Since npx could find and run the tool, I knew the package was functional. The failure was isolated to calling the command directly after a global install.

I needed to understand why npm couldn't find its own installation. I ran npm root -g, a command that shows the directory npm uses for global packages:

C:\Users\<user>\AppData\Roaming\npm

This told me exactly where npm had placed the executable files. Next, I checked my system's search paths using echo %PATH%. This command displays the list of directories Windows scans when looking for executables. The output showed entries for Windows system folders, Git, and Java, but the AppData\Roaming\npm directory was completely missing.

Root Cause
The root cause turned out to be the PATH environment variable all along.

On Windows, npm does not automatically add its global bin folder to your system PATH in every scenario. Depending on how Node.js was installed or updated, that critical path entry can get left behind. My echo %PATH% confirmed the directory where npm drops executables wasn't in the search list. Because the path was missing, Windows had no way to resolve markdown-it-cli when I typed it.

Final Solution
Fixing this required updating the environment variables, but there's a trap that caught me out. I opened Windows Environment Variables and added %AppData%\npm to the User PATH variable. This points directly to where npm root -g indicated my tools lived, ensuring Windows would find the executable.

I saved the change and immediately tried running markdown-it-cli in my current terminal window. It still failed with the same error.

The trap was that a running terminal holds the PATH snapshot from when it started. Updating environment variables doesn't retroactively fix an open session; the terminal process has already loaded its configuration. I had to close all terminal windows and open a brand new one for the OS changes to apply.

Once I opened a fresh terminal, running markdown-it -v worked perfectly. The command was recognized and executed as expected, confirming the fix.

Lesson Learned
When a global CLI installs successfully but won't run, don't rush to reinstall or blame the package. Before doing anything drastic, follow this diagnostic path:

Run npm root -g to find where npm installed the tool.
Check if that directory exists in your %PATH% using echo %PATH%.
If the path is missing, add it to your User PATH and open a new terminal.

Fixing the environment variable saves you from wasting time on package reinstalls and gets your global tools working again. Always verify the path before assuming a broken install.

Written from real hands-on experience, drafted with AI assistance.

Local LLM vs Cloud API: My Mac Mini Cost Crossover

DevLog — Thu, 27 Aug 2026 01:23:02 +0000

The Problem
I run an automated content pipeline (blog + YouTube Shorts) on a Mac mini with 48GB of unified memory. For months, my cloud LLM API (GLM) free tier handled everything comfortably at 60 RPM. Then, late last year, they quietly dropped the limit to 5–10 RPM overnight. My TTS pronunciation-QA batch script (qa_shorts.zsh + pron_map.py) started validating dozens of Shorts scripts and immediately hit the wall. The pipeline stalled for hours, waiting on retries while I watched tokens burn through my quota.

Attempts & Failures
The obvious fixes were throttling and retrying, but 5–10 RPM is brutal for bursty workloads. Backoff delays turned a short batch job into an hours-long crawl, and the queue behind it backed up every time. The bottleneck wasn't technical—it was the hard rate cap.

Root Cause
The real issue was a mismatch between my workload pattern and the pricing model. GLM charges per token, which works for steady, low-volume usage, but my pipeline is inherently bursty. When qa_shorts.zsh fires off dozens of requests in a tight window, the 5–10 RPM limit turns a two-minute job into a four-hour stall. Meanwhile, my Mac mini is already running 24/7 for background tasks like video restoration and encoding. I was paying a premium for compute I already had sitting idle, just because the cloud provider decided to throttle my free tier. The crossover point isn’t about raw price; it’s about how your requests per minute and tokens per job interact with rate caps.

Final Solution
I spun up LM Studio locally and loaded Qwen 35B-A3B (an uncensored "Heretic" fine-tune optimized for MLX, Apple’s native machine learning framework). I pointed it to the OpenAI-compatible endpoint at localhost:1234 and wired it directly into my pipeline. The crossover became clear immediately: for high-volume, repetitive tasks like pronunciation QA and bulk rewriting, the local model wins on every metric. Zero marginal cost (just electricity), no rate limits, and full privacy over my script drafts. For hard reasoning or long-context quality checks, I kept the cloud subscription model, which still offers a flat monthly fee with generous quotas. I implemented a simple fallback chain: cloud API first, local Qwen as the retry target during rate-limit storms. The stalls vanished, and the pipeline resumed its normal cadence without manual overrides.

Lesson Learned
Don’t trust vendor marketing when picking your LLM strategy. Measure the crossover with your own workload numbers—requests per minute, tokens per job, and batch distribution. In my case, it wasn’t price that forced the migration; it was rate limits. Once I mapped those numbers to my Mac mini’s 48GB unified memory and wired up a hybrid fallback, the pipeline ran smoother than ever.

Written from real hands-on experience, drafted with AI assistance.

My Local LLM Was Running at 1.6% of Its Context. Here's the Setting That Fixed It

DevLog — Tue, 25 Aug 2026 09:06:37 +0000

I run a content pipeline on a Mac mini (48GB unified memory) that splits long blog drafts into platform-specific short-form pieces. That job — read a 30-page document, hold the whole thing in mind, extract what matters for YouTube Shorts vs TikTok vs Reels — is exactly what long-context LLMs are supposed to be good at.

Mine wasn't. It kept "forgetting" the second half of every document, dropping key details, and producing shallow summaries no matter how I tuned the prompt.

Three weeks of tuning the wrong thing

I did what you'd do. Simplified the prompt. Rewrote the template. Swapped models. Re-downloaded them, twice. Spent entire evenings after work on this, convinced the model was the problem — a Q4_K_M quantized 13B–20B model should handle long documents, right? The symptoms said otherwise: solid on the first pages, incoherent by the end.

Classic context-window behavior. I just didn't see it yet.

The one line in the console

Then I actually read the LM Studio load log instead of scrolling past it:

context_length: 4096

The model I was running supports 262,144 tokens of context. It was loaded with 4,096.

That's 1.6% of what the model can do. A 48-lane highway restricted to one lane — and every long document I fed it was quietly getting truncated into memory of just the opening section.

Why it happened

LM Studio's just-in-time model loading picks a conservative default context length on first load. For chat and short Q&A, 4096 is plenty and keeps memory pressure low — a sensible default for most users. For document-scale work, it's a silent killer. Nothing errors out. Nothing warns you. The model just appears to have a bad memory.

Context is the model's working memory. Cap it at 4k tokens and a 30-page brief becomes "read the first two pages, forget the rest."

The fix

Two things:

Set context length explicitly on load. In LM Studio's model settings, Context Length: 260000 (whatever your model supports — check the model card, not the default), then reload. On 48GB of unified memory the larger KV cache is entirely affordable.
Guard against silent reloads. I added a simple flag to the pipeline so an in-flight job blocks model reloads. The default resetting itself mid-workflow is how you get this bug back.

The result

Immediate, dramatic improvement. Full-document comprehension, per-platform extraction without drift, details intact end to end. Same model, same hardware, same prompt — one setting was capping ~98% of the model's effective utility for my workload.

The lesson

Defaults are tuned for the average case, and document-scale synthesis is not the average case. When a local LLM "feels dumb," check what it was actually loaded with before blaming the weights:

Find the real context limit on the model card
Read the load log — what context_length is actually in effect?
Set it explicitly, every time, in your load scripts

The most expensive performance bug I've shipped was a single default value.

This post is based on a first-hand work log, written with AI assistance.

Running Tailscale Without sudo: The Userspace-Networking Trade-offs Nobody Mentions

DevLog — Mon, 24 Aug 2026 08:44:15 +0000

Corporate policy: no admin rights on my work laptop. My problem: I needed to reach that machine — and SSH into my other machines — from a Galaxy Tab while away. Filing a VPN request with the security team would mean paperwork and a hard no for personal tooling. And without the sudo password, installing anything system-level is off the table.

That's when Tailscale's userspace-networking mode caught my eye: a VPN that runs entirely in user space. No root, no system service, no TUN driver. It sounded too good to be true, and in a few ways, it was.

Install: the easy part

brew install tailscale

The CLI formula installs without admin rights. (The GUI app comes as a cask — which needs sudo, so that's out.) The real work starts with the daemon: normally tailscaled registers as a system service, but in userspace mode you run it yourself:

nohup tailscaled --tun=userspace-networking \
  --statedir=$HOME/.tailscale \
  --socket=$HOME/.tailscale/tailscaled.sock &

The key detail: point statedir and socket somewhere under $HOME. Everything else about this setup flows from that one decision.

Gotcha #1: the socket path

With the daemon running, I tried tailscale status and got a "socket not found" error. The daemon was alive — I'd just started it. What happened?

The CLI looks for the socket at the system default (/var/run/tailscale/tailscaled.sock). In userspace mode it actually lives at $HOME/.tailscale/tailscaled.sock, and the CLI won't guess. Every command needs the flag spelled out:

tailscale --socket=$HOME/.tailscale/tailscaled.sock status
tailscale --socket=$HOME/.tailscale/tailscaled.sock ip
tailscale --socket=$HOME/.tailscale/tailscaled.sock set --ssh

Typing that path five times a day gets old fast. A shell alias fixes it:

alias ts='tailscale --socket=$HOME/.tailscale/tailscaled.sock'

I wish I'd set that up on day one instead of week two.

Gotcha #2: it's not a full VPN — it's a SOCKS5 proxy

This is the one that cost me an evening. I turned on Tailscale's built-in SSH (ts set --ssh), connected from the Tab to the laptop's tailnet IP — worked beautifully. Then I tried browsing an internal site from a browser and... nothing.

Here's what's actually happening under --tun=userspace-networking: it's not a system-level VPN. Traffic moves through a SOCKS5 proxy, which means apps don't route through Tailscale automatically. Anything that needs the tailnet has to be pointed at the proxy explicitly — browser proxy settings, curl --socks5, and so on. A real VPN is a highway all traffic uses; this is a special pass one road accepts.

So: inbound SSH to my machines, perfect. Arbitrary apps reaching the tailnet, manual configuration per app.

Gotcha #3: reboots

nohup keeps the daemon alive after you close the terminal, but it isn't registered with launchd. Every reboot, the daemon is gone — and there's no systemd unit equivalent you can install without sudo. I lost a few mornings to "why won't it connect" before the muscle memory of re-running the launch command kicked in. A note in my shell rc file with the exact command helps more than you'd think.

Also worth knowing: in userspace mode, the machine can accept inbound connections but won't route its own outbound traffic through the tailnet by default. Testing "can I reach my own Tailscale IP" from the same machine times out — that's expected behavior, not a broken install.

What worked out of the box

Tailnet joined cleanly; the laptop picked up its 100.x.x.x IP immediately
tailscale set --ssh gives you SSH without opening port 22 or touching macOS Remote Login settings — this alone justified the setup
Connecting from the Galaxy Tab to the laptop over the tailnet: zero issues
All state and logs live under ~/.tailscale/, easy to inspect

The honest scorecard

No-root constraint forces trade-offs, and this is what they look like:

Works: inbound SSH via Tailscale's built-in server; brew install with no admin; SOCKS5 proxy for per-app access; survives terminal close (nohup)
Doesn't: system-wide VPN routing; the GUI app (needs sudo); apps auto-routing through the tailnet; surviving a reboot (no launchd without root)

Takeaways

Read the mode name literally. "Userspace networking" means userspace constraints: user-level socket paths, user-launched daemons, per-app proxies.
Alias the socket flag on day one. Future-you will be grateful.
Official guides assume the standard install. Every doc that says "just run tailscale status" silently assumes the system daemon. Under constraints, expect one layer of translation between the docs and your reality.
If you only need inbound SSH, this is nearly perfect. The proxy awkwardness only bites when you want general outbound tailnet traffic.

This post is based on a first-hand work log, written with AI assistance.