DEV Community: MilkyWay008

Qwen Code 400 "failed to parse grammar" against llama.cpp? Here's the fix

MilkyWay008 — Wed, 02 Sep 2026 17:05:56 +0000

If you run Qwen Code against a local llama.cpp server, you may have woken up one morning to every request dying with:

API Error: 400 Failed to initialize samplers: failed to parse grammar

Before any token comes back. The model never even starts. And here's the annoying part. The same model works fine if you curl the endpoint directly, and it works fine if you're running a different model like gemma. So it's natural to blame the model, the server, the quant, whatever.

It's none of those. This is a tool-schema bug in Qwen Code, and an auto-update is what shipped it to you. Here's what's actually happening, plus the one-line settings fix that survives the updater.

What's actually breaking

llama.cpp doesn't do free-form JSON tool calling. When a client sends tool schemas, llama.cpp compiles every registered tool's JSON Schema into one big constrained-decoding grammar at sampler init. That grammar has to parse before the model generates a single token.

Qwen Code 0.22.3 registers a bunch of built-in tools, and a few of them carry string maxLength limits way past what llama.cpp's grammar converter can represent. report_findings has maxLength: 2000/4000/4096. send_message has 65536. loop_wakeup has 10000. The converter chokes, the grammar fails to parse, and you get your 400 before any generation starts.

The Qwen maintainer confirmed it. Strip those length limits and the same tool set parses clean. Include report_findings and it fails with exactly this error.

That's also why gemma "works fine". The failure isn't model-specific, it's grammar-size-dependent. Models whose tool set stays under the cap never see it. Models pulling in the heavy built-ins trip over it.

The fix: defer the tool schemas

Qwen Code ships a tools.eager setting that controls which tool schemas go into that initial request. The counterintuitive part: set it to an empty list.

{
  "tools": {
    "eager": []
  }
}

Put that in ~/.qwen/settings.json (a project-level .qwen/settings.json works too, same shape), restart Qwen Code, done.

An empty eager list doesn't disable anything. It defers every non-exempt built-in tool schema out of the initial request, so the grammar stays small enough to parse, while the tools themselves stay registered and callable on demand. Think of it as: don't announce every tool up front, resolve them when actually used.

Two gotchas while you're in there:

Don't bother with "tools": { "core": [] }. It doesn't shrink the eager schemas. People still got the 400 with 23 schemas riding in the request.
If you're on an older workaround that used permissions.allow to shrink schemas, that's dead. permissions.allow is pure auto-approval now, it no longer affects schemas. tools.eager is the knob.

But I'm on auto-update and it keeps coming back

This is the part that stings. The broken behavior shipped in a stable auto-update (0.22.3), and the actual fix only lands in the nightly channel so far. Pin stable and you stay broken. Let it auto-update and it drags you back onto the broken build.

The merged fix (it strips the report_findings maxLength limits) is in the nightly line:

npm i -g @qwen-code/qwen-code@nightly

Prefer stable? Then the tools.eager: [] workaround above carries you through. It's version-independent and doesn't fight the updater.

One honest caveat. The merged fix only strips the limits on report_findings. A couple of other built-in tools still carry big maxLength values (send_message at 65536, for example), so on an exotic model and server combo the grammar could still overflow. Keeping eager: [] in your settings is cheap insurance until the stable release catches up.

The pattern worth remembering

This whole class of bug is going to keep showing up as more coding agents target local llama.cpp servers. The client sends every tool schema it knows, llama.cpp has to compile them all into one grammar, and one oversized schema takes down the whole request. So if you ever see "failed to parse grammar" from a llama.cpp-based server, your first suspect shouldn't be the model. It's whatever JSON schema payload your client just sent. Check the request, look for the giant maxLength fields, and find your client's version of tools.eager to defer them.

I hit this myself running Qwen Code against a local server after an auto-update, and the error message pointed everywhere except the actual cause. The fix is tracked in qwen-code#10530 and qwen-code#10435; the upstream fix is PR #10275.

Codex CLI bricks every command after an update — the wire_api config trap

MilkyWay008 — Tue, 01 Sep 2026 17:05:08 +0000

If you updated Codex CLI recently and suddenly every command dies with Error loading config.toml, it's probably not your setup. One stale line in a config block you might not even use anymore is enough to brick the whole thing. I ran into this exact pattern, and here's the fix.

The symptom

Upgraded to Codex 0.151.0, then:

Error loading config.toml: `wire_api = "chat"` is no longer supported.
How to fix: set `wire_api = "responses"` in your provider config.
More info: https://github.com/openai/codex/discussions/7782
in `model_providers.token-plan.wire_api`

Every command dies at config load. codex login status dies. codex exec dies. Only codex doctor still runs, and it reports config.load: fail. If you've got a provider block in config.toml that you stopped using months ago, it still gets validated on startup, and one stale value takes everything down with it.

The root cause

Codex validates every [model_providers.*] block in config.toml at startup, not just the one you're actively using. And wire_api = "chat" was removed from the CLI entirely. Chat/completions support is gone as of early 2026. So an entry that's never referenced by your active model provider, any profile, or --model still trips the validator and kills every command.

There's no codex config migrate command, no migration path. You fix it by hand.

The fix

Locate the config. %USERPROFILE%\.codex\config.toml on Windows, ~/.codex/config.toml on Linux/macOS. If CODEX_HOME is set, that overrides the directory.
Find the stale block. Look for [model_providers."<name>"] blocks with wire_api = "chat":

[model_providers.token-plan]
name = "token-plan"
wire_api = "chat"        # <-- this line

Fix it one of two ways:

Delete the whole block if you don't use that provider anymore, or
Change the line to the currently valid value:

wire_api = "responses"

That's it. Flipping just that one line gets codex exec moving again. Both fixes are confirmed by people who hit this.

The lesson

When a CLI releases a version that removes a config value, check your whole config file for stale entries, not just the section you're actively using. Eager validation means an unused block can still brick startup. And if an upgrade doc says a value is deprecated, plan to remove it before you upgrade, not after the tool stops working.

Full thread: https://github.com/openai/codex/issues/41816

jinja2 imports fine but jinja2.compiler is missing: the Python partial-install trap

MilkyWay008 — Mon, 31 Aug 2026 17:07:26 +0000

jinja2 imports fine but jinja2.compiler is missing: the Python partial-install trap

There's a classic failure that shows up over and over in Python CLI bug trackers, and it's almost never a bug in the tool. Someone posted it recently in the aider repo. Windows 10, Python 3.10.9, no venv, plain system install. Every launch died instantly:

ModuleNotFoundError: No module named 'jinja2.compiler'

The traceback pointed through litellm -> arize -> jinja2.environment. And the odd part: import jinja2 worked fine. Only the compiler submodule was missing.

That's the tell. When a top-level package imports cleanly but one of its submodules is missing, the tool you're running is probably innocent. Your environment is broken. Two things cause this, and both take about two minutes to fix.

Cause 1: a partial install

pip was mid-write when something interrupted it. A dropped connection, a killed terminal, a power blip. Or an upgrade went sideways and left the package half-installed: the .dist-info metadata landed, some modules landed, but compiler.py never did. Python doesn't complain until something actually tries to import the file that isn't there.

Cause 2: shadowing

Python adds the directory you're running from to the front of the module search path. If there's a stray jinja2.py or a jinja2/ folder sitting in that folder, Python imports it instead of the real installed package. The imposter has no submodule, so the tool dies with a confusing error.

The issue thread even had a diagnosis comment naming exactly this. GitHub auto-minimized it as spam, which is its own kind of annoyance, but the content was right.

The fix, in order

1. See where the package actually resolves from

python -c "import jinja2; print(jinja2.__file__)"

If the path is your current working directory or anything outside site-packages, you've got shadowing. Run the tool from a different folder, or delete the stray file. Check for a folder too, both count.

2. Force a clean reinstall

pip skips packages it thinks are already installed. The flag that makes it reinstall anyway:

pip install --upgrade --force-reinstall jinja2

Then confirm the submodule imports now:

python -c "import jinja2.compiler"

If nothing prints and nothing raises, you're done.

3. Check for other broken deps while you're here

python -m pip check

This lists packages whose requirements aren't satisfied. If something else is half-broken, you want to know now, not after the next random crash.

4. The proper long-term fix: a venv

If you're running tools against a system Python that's been through years of installs and upgrades, this will bite again eventually. The clean move is to stop using system Python for this:

python -m venv venv
venv\Scripts\activate     # Windows
# Linux/macOS: source venv/bin/activate
pip install aider-chat

Everything lives in one folder, the mess of your system site-packages can't reach in, and if it ever breaks you delete the folder and start over. That's also what the folks in the issue thread recommended.

Caveats

If reinstalling jinja2 doesn't fix it, reinstall the top-level app instead. That drags in a consistent set of deps and often repairs the whole mess.
The original reporter never posted back which fix worked for them, so I can't say whether partial-install or shadowing was theirs. Both are cheap to test.
This isn't jinja2-specific. Any "package imports fine but submodule is missing" error, pydantic or requests or whatever, has the same two causes and the same fix path.

The general lesson

Next time a Python CLI dies at startup with a ModuleNotFoundError for something you know is installed, don't go read the tool's source. Ask two questions: where is it resolving from, and is the install actually complete? One command answers the first, one flag fixes the second.

Original thread: https://github.com/Aider-AI/aider/issues/5653

Aider Says 'No Endpoints Found' — Your Model Was Retired, Here's How to Fix It

MilkyWay008 — Sun, 30 Aug 2026 17:08:17 +0000

Your AI coding tool was working fine yesterday. Today it 404s on every request with something like "No endpoints found for anthropic/claude-3-opus." and you're wondering what broke.

Nothing broke on your end. The model you had configured was retired by the provider, and your tool is just relaying the bad news.

What actually happened

Aider (and most agent CLIs) route chat through a provider like OpenRouter. OpenRouter doesn't actually host models — it fronts providers — and when a model is retired, it usually stays in the catalog with an empty endpoint list. Every request against it fails with the same 404:

httpx.HTTPStatusError: Client error '404 Not Found' for url 'https://openrouter.ai/api/v1/chat/completions'
litellm.OpenRouterException: {"error":{"message":"No endpoints found for anthropic/claude-3-opus.","code":404},...}

That "No endpoints found" message is OpenRouter's standard response for a model that no longer exists. It's not an aider bug, it's not a config typo, it's not your API key. The model slug you're using is gone.

How to check in 10 seconds

Confirm the slug is actually dead before you touch anything:

curl https://openrouter.ai/api/v1/models | grep -c claude-3-opus

Zero hits means the model is gone from the catalog. (You can also open the model's page in a browser — it'll 404.)

The fix

List the models your tool can actually use now. For aider:

   aider --list-models openrouter/

Pick a current slug and switch to it. For aider:

   aider --model openrouter/anthropic/claude-opus-4.7

Or edit your config file / AIDER_MODEL env var to match.

Fix the misleading crash that hides the real error. On Windows, aider renders errors through Rich, and the legacy console path can throw a second OSError: [Errno 22] while printing the traceback. It looks like a second bug but it's just console-render noise. Run from Windows Terminal instead of the old conhost (or use aider --no-color) and the real error shows up cleanly.

The general rule: when a provider-backed agent CLI starts 404ing at the API, check the model slug first. It's the cheapest thing to test, and retired slugs are a recurring fact of life — providers bump model generations constantly, and old IDs don't stay live forever.

LM Studio silently broke my model load after a runtime auto-update — the NTSTATUS exit code decode

MilkyWay008 — Sat, 29 Aug 2026 17:09:27 +0000

If you run local LLMs on Windows with an NVIDIA GPU, you've probably seen LM Studio's "runtime extension packs." They're the bundled CUDA/ROCm/Vulkan builds of llama.cpp that actually run your models. And by default, LM Studio auto-updates them in the background.

That bit me on an RTX 5090. One day a model that had loaded fine for days suddenly refused to load. The dialog just said:

Failed to load the model / Error loading model. / (Exit code: 18446744072635812000). Unknown error. Try a different model and/or config.

No hint of what the number meant. No hint of what broke. The model file was untouched, config untouched, driver untouched. The only thing that changed was the runtime.

The exit code is a Windows NTSTATUS, not a random number

That huge unsigned value isn't a random roll of the dice. Convert it to hex and you get 0xFFFF_FFFF_C000_08A0 — a sign-extended NTSTATUS. The low 32 bits, 0xC00008A0, are the actual error status.

NTSTATUS values are how Windows reports driver and kernel-level failures. The UI doesn't translate them, so you get a wall of digits. If you ever see a giant unsigned exit code like this in a local-LLM tool, convert it to hex and check the low 32 bits. That tells you you're dealing with a driver/CUDA-level failure, not something wrong with your model file.

The real error was hiding in the logs

The dialog didn't tell me anything useful, but LM Studio's Developer > Local Server logs did. There I found the actual CUDA error: CUDA error: shared object initialization failed in launch_fattn (the flash-attention kernel), with the model's Gated Delta Net fallback path logged as unsupported and disabled. The runtime was crashing in a specific kernel on the Blackwell architecture.

Cross-referencing the upstream llama.cpp issue tracker confirmed it: the CUDA 12 runtime v2.27.1 has a broken fallback path on RTX 5090 (sm_120). It's not your model. It's not your config. It's the runtime build.

The fix: roll back the runtime pack

LM Studio runtime extension packs are versioned, and you can pin an older one. In LM Studio: Settings > Runtime, pick the older CUDA 12 build (v2.25.2 worked for me), and the model loads again immediately. No re-download of the model, no config changes, no driver reinstall.

While you're in there, turn off "Auto-update selected Runtime Extension Packs". It defaults to on, and it's what silently swapped in the broken build in the first place. Leave it off until the fixed runtime ships.

The general lesson

Any local-LLM tool that bundles a runtime — LM Studio, Ollama, llama.cpp servers — can silently swap that runtime on update. The failure signature to watch for:

A model that loaded fine suddenly fails, with nothing else changed.
A cryptic huge unsigned exit code and "Unknown error" in the UI.
Logs that name a specific CUDA kernel or a "not supported / disabled" fallback path.

When you see that combo, don't re-download the model and don't reinstall drivers. Check the runtime version first. Roll it back, disable the auto-update, and carry on. New GPU architectures (Blackwell included) are where these runtime regressions bite hardest, because the fallback paths are new and rarely exercised until real users hit them.

If you want the full thread: lmstudio-bug-tracker issue #2234 and the upstream llama.cpp issue #26481.

Your Browser Automation Hangs After an Update? Check the Keychain Flags

MilkyWay008 — Fri, 28 Aug 2026 17:14:43 +0000

Your Browser Automation Started Hanging After an Update? Blame the Keychain

If you run browser automation on a Mac or Linux box, you may have hit this one recently: your script worked fine for months, then after a library update the headless browser just... never starts. No error, no crash, just a hang and a timeout 30 seconds later. Or worse: on a desktop, a macOS Keychain password dialog pops up every time a fresh browser profile launches, asking for a password your script doesn't know.

I hit this exact thing with browser-use, and it took a while to track down, because nothing about the failure looks like what it is. This is what's happening and how to fix it.

What you see

Symptoms vary by platform, but the shape is the same:

Headless / CI: BrowserSession.start() hangs. The Chromium process starts, but the CDP debug port never opens. The watchdog eventually gives up with something like TIMEOUT ERROR - Handling took more than 30.0s or Browser did not start within 30 seconds.
Interactive desktop (macOS): a Keychain password prompt pops on every launch of a fresh browser profile. Say no or let it sit, and you get the hang.
Linux with a keyring daemon: same hang when gnome-keyring or kwallet is registered.

It's fully deterministic. One minute the browser starts in a second, the next it blocks forever.

What's actually happening

The root cause is in the browser automation library's default Chrome arguments. browser-use used to launch Chromium with two flags:

--use-mock-keychain
--password-store=basic

These tell Chromium to skip the OS credential store entirely. Browser automation doesn't need to decrypt your saved passwords; a fresh temporary profile has nothing in the keychain anyway.

Then a PR (browser-use#3225, "fix-auth") removed both flags. The intent was reasonable: if you point the tool at a real user Chrome profile, Chromium needs keychain access to decrypt saved passwords and cookies. But the flags were removed globally, not just for real profiles. So now browser-use-managed profiles (temp dirs, the default profile dir) also touch the OS credential store.

And here's the kicker: Chromium's profile init synchronously calls into the credential store on startup. On a headless box with no interactive session to answer, that call blocks forever instead of failing fast. The browser never finishes starting, so the CDP port never opens, and the 30-second watchdog does its thing.

You can verify it yourself. Run Chromium with the flags:

"$CHROME_BIN" --headless=new --use-mock-keychain --password-store=basic \
  --user-data-dir=$(mktemp -d) --remote-debugging-port=9334

CDP responds in about a second. Drop the flags and the same command just sits there.

The fix

The proper fix (re-adding the flags for managed profiles only) is still in review upstream as of this writing — three PRs have been proposed and none merged. So for now, the workaround is on your side.

Option 1: pass the flags yourself. With browser-use, BrowserProfile accepts extra args:

from browser_use import BrowserProfile, Browser

profile = BrowserProfile(
    headless=True,
    args=["--use-mock-keychain", "--password-store=basic"],
)
browser = Browser(profile=profile)

Option 2: pin the version. The regression shipped in the flag-removal PR, so anything after that release is affected. If you don't need the newest features, pin to the last version before the change and move on.

Option 3: patch it locally. If you're stuck on a newer version, add the two flags back to CHROME_DEFAULT_ARGS in browser_use/browser/profile.py. It's two lines, and it'll survive until a proper fix lands.

The broader lesson

This one generalizes beyond browser-use. If an automation tool starts hanging or prompting after an update, and the process is alive but never becomes ready, check the launch arguments before you blame the network or the tool itself. Tools that add flags to make real-user features work can silently break the disposable-profile path — the default case for automation.

Also worth remembering: when a headless process blocks on a credential store, the failure signature is a hang, not an error. No log line tells you "I'm waiting for keychain access." The process is just stuck in a syscall, and only a launch-arg diff (or a thread dump showing the stuck call) reveals it.

If you're building tooling that wraps Chromium, keep the mock-keychain flags for managed profiles. Real user profiles need the keychain; disposable automation profiles never do, and mixing the two is how you get 30-second hangs in CI at 2am.

The issue is tracked here: browser-use/browser-use#5415. If you're hitting this, thumbs-up the issue and the fix PRs so it actually lands.

Windows freezes and shuts down after an update? Here's the 5-step fix

MilkyWay008 — Thu, 27 Aug 2026 17:15:07 +0000

Windows freezes and shuts down after an update? Here's the 5-step fix

Every few months the same post shows up in the help forums: "Updated Windows, now my PC randomly freezes, sometimes powers off by itself, and the clock is wrong." Zero troubleshooting done, a dozen replies telling them to reinstall Windows.

Before you nuke the install, there's a method that sorts out most of these. It takes about an hour, costs nothing, and it starts with figuring out whether Windows actually broke, or whether the update just exposed a driver that was always one bad day away from crashing.

What's actually going on

When a cumulative update lands and your machine starts hard-freezing, the freeze (trackpad, keyboard, power button all dead) is almost always a driver or firmware component that stopped responding after the update changed how it talks to the kernel. Windows records that as a watchdog timeout. The random shutdowns are usually the same story, or the machine's thermal/power protection tripping.

The clock drift is a separate symptom. The Windows Time service gets into a bad state, or the system never syncs properly after all those unclean shutdowns. Don't let it distract you, but don't ignore it either, fix the freezes first, then fix the clock.

Here's the order that works.

Step 1. Event Viewer first, always

Open eventvwr.msc, go to Windows Logs > System, and look at timestamps around the freezes. You're hunting for two things:

Kernel-Power Event 41 means the machine lost power without a clean shutdown. It's the "unexpected shutdown" event, and on its own it just tells you something died.
WHEA-Logger errors are hardware failures reported by the CPU/chipset. If you see those, you're looking at a hardware problem, not an update problem, and the fix path changes completely.

The giveaway for the update-caused case is a watchdog bugcheck like 0x1CA (SYNTHETIC_WATCHDOG_TIMEOUT) pointing at a driver that stopped responding. Event 41 plus no WHEA errors plus a watchdog bugcheck after a fresh update = driver hang, not dead hardware. That's the case this article covers.

Step 2. Roll back the suspect update

Windows Update keeps the last few cumulative updates around for exactly this. Settings > Windows Update > Update history > Uninstall updates, pick the most recent one, uninstall it, and pause updates for a week:

wusa /uninstall /kb:5121003

(substitute the KB number you're actually rolling back). Then Settings > Windows Update > Pause updates, and use the machine normally for a couple of days.

Does the freezing stop? Then that update was the trigger. You can reinstall it later, but first do Step 5, because the update didn't cause the bug, it exposed one.

If it still freezes after the rollback, you've ruled out the update, and you're into hardware territory: RAM test (MemTest86), temperature check, PSU suspicion.

Step 3. Fix the clock

Once the machine is stable again, resync the time from an admin command prompt:

w32tm /resync

If the clock keeps drifting or resets to the BIOS default when the machine is fully powered off, it's a CMOS battery, a $3 part on most laptops. If it just drifts while running, the time service is unhealthy, and a resync usually fixes it.

Step 4. Repair the system image

Unclean shutdowns corrupt files. Before you blame the drivers, let Windows fix itself. Boot into Safe Mode, open an admin command prompt, and run these in order:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

DISM repairs the image, sfc fixes system files against the repaired image. Run DISM first, then sfc. They take a while, let them finish.

Step 5. The actual fix: OEM drivers and BIOS

Here's the part people skip. A cumulative update doesn't usually write your drivers, but it can change kernel behavior enough that an old, buggy driver stops working. The lasting fix is almost always the laptop maker's own updates:

Go to your OEM support page (Acer, Dell, HP, Lenovo, whoever).
Update the chipset driver, the GPU driver, and the storage driver.
Update the BIOS. This is the big one. Freeze-after-update issues that survive driver updates are frequently fixed in BIOS releases.

Then reinstall that Windows update you rolled back in Step 2 and test again.

The honest caveat

This method assumes the update is the trigger, not the cause. If you roll back and the machine still freezes, or you see WHEA errors, stop treating it as a software problem. Check temperatures, run a memory test, and if it's still under warranty, use it.

Also worth saying: this is the procedure, not a promise. Your exact laptop may have a weird quirk this doesn't cover. But in my experience, most of these posts end up being a driver that finally got caught, and the OEM's chipset + BIOS updates fix what the rollback only masked.

Start with Event Viewer, not the reinstall USB.

Windows Smart App Control Is Blocking Your Python CLIs (os error 4551) — What To Do

MilkyWay008 — Wed, 26 Aug 2026 17:12:24 +0000

If you've seen this error on Windows 11, you probably assumed your install was broken. Easy to think that. The tool dies at spawn. No Python traceback, no error inside the app. Nothing. The actual problem isn't your tool at all.

What's actually happening

Smart App Control (SAC) is Microsoft's consumer version of WDAC, the Windows Defender Application Control. When it's in enforcement mode it runs a policy called VerifiedAndReputableDesktop. That policy only lets executables run if they're signed by a trusted-root CA and known to Microsoft's reputation system.

Here's the catch: uvx, uv tool install, and pipx all generate small .exe launchers for your CLI at install time, and those launchers are unsigned. Authenticode says NotSigned. Code Integrity shoots the shim down before your tool ever starts. The tool is fine. The little launcher that boots it is what got blocked.

You can confirm it in Event Viewer under Applications and Services > Microsoft > Windows > CodeIntegrity > Operational. Events 3033 and 3077 are the blocks, and 3089 logs the signature info (you'll see TotalSignatureCount 0). If those are there, it's the policy, not your install.

If the same tool ran fine last week, check whether SAC got switched on in the meantime. That's usually the trigger.

How to keep working

Run the same code through a signed interpreter. This is the workaround that works today:

# instead of:
uvx browser-use

# run the module through Python instead:
uvx --from browser-use python -m browser_use.cli

Same idea inside a venv:

python -m browser_use.cli

python.exe is Microsoft-signed, so it sails through and the unsigned shim never executes. This works for any package with a runnable __main__ block, which is most CLI packages. If yours doesn't have one, call the library API directly instead of going through the CLI subprocess.

Don't bother looking for an allowlist. Consumer SAC has no per-app bypass. Microsoft is explicit about it: there's no way to allow one specific app. And don't turn SAC off to make a tool work either. It's binary, and once it's off the only way back is a clean reset of Windows. That's a terrible trade for one CLI.

The real fix is upstream. The only thing that fully unblocks an SAC-enforced machine is a signed release from the project. Neither uv nor pipx has a flag to sign the launchers it generates, so it's on the tool authors. Flutter ran into the same wall with its unsigned Dart runtime, so this isn't some browser-use-only quirk. If you're affected, say so on the issue. Maintainers pay attention when enough people show up.

The lesson

When a Windows CLI dies instantly with os error 4551, check the CodeIntegrity operational log before you reinstall anything. 3033/3077 means an unsigned launcher hit an App Control policy. The fix is usually to call the same code through a signed interpreter, not to chase a broken install.

And if you maintain a Python CLI, sign your releases. On an SAC-enforced machine, an unsigned launcher is a dead launcher, and there's no workaround your users can apply that fully fixes it.

Your AI coding tool broke after an auto-update? On Windows, check the self-lock first

MilkyWay008 — Tue, 25 Aug 2026 17:11:57 +0000

I've been collecting these reports for a while now, and there's a pattern. Your AI coding assistant says "Update complete!", you click it, and then... the tool won't start. Or it crashes. Or every launch says "the next launch will retry" forever.

It's not bad luck. It's Windows file locking meeting self-updaters that report success before anything actually finished.

The pattern

AI coding tools update themselves. On Windows that means replacing .exe files, renaming venv folders, rewriting npm shims. And Windows will not let you replace a file that's running, or rename a folder a process has open.

Look at what people actually hit:

hermes update fails with [WinError 32] ...hermes.exe -> hermes.exe.deleteme. The updater IS hermes.exe, so it can't replace itself. Then it drops a .update-incomplete marker, and every launch retries the update and fails again. Permanent loop.
The same updater can't "park" its own venv: WinError 5 Access denied renaming venv to venv.stale.runtime-*, because leftover gateway and desktop processes spawned from inside that venv still have python.exe open.
Claude Code auto-updates 2.1.236 to 2.1.237 and leaves a 500-byte claude.exe stub that prints "Error: claude native binary not installed." The Windows platform package was never published to npm, and the updater logged success anyway.
cline update half-writes the global npm install and the cline command just vanishes from PATH.

The common thread: the updater replaces files while old processes still hold them, and it reports success regardless.

Why "Update complete!" lies to you

Three things stack up:

Windows locks files that are in use. A running exe can't be swapped. A directory a process is sitting in can't be renamed. On Linux, unlinking an open file works fine; Windows says no.
Self-updaters skip themselves in their own "is anything running?" check. The process doing the updating excludes itself and its ancestors from the lock scan, so it never sees the conflict right under its nose.
Exit code 0 doesn't mean done. The updater prints "Update complete!" because the shell command returned 0, even when the file it needed to write never landed.

The fix recipe

When your agent CLI breaks after an auto-update on Windows, go through this in order:

Kill everything from the old install. Task Manager: the CLI, the desktop app, the gateway or background server, stray node.exe processes. Quit tray apps properly, then check again, because many of these keep a background daemon alive.
Clear stale markers and caches. Look for .update-incomplete, update-in-progress, venv.rollback-bak-*, generation-*, and __pycache__ folders under the install dir and delete them. If node_modules is half-installed, delete it too.
Update from a clean shell outside the app's own process tree. Don't run the updater from inside the tool's own terminal. For hermes specifically, python -m hermes_cli.main update runs the updater via python.exe instead of the launcher, so the file being replaced isn't the one running the update.
Verify, don't trust. After updating, run claude --version / hermes --version / cline --version. Check the binary is actually a binary, not a stub: dir the exe and look at the size. For npm-installed CLIs, npm view <pkg>@<version> confirms the package exists before you re-run the update.
Pin or downgrade as a stopgap. If the new version is broken, install the last known-good one explicitly: npm i -g cline@<oldver>, npm install -g @anthropic-ai/claude-code@2.1.236. A working older version beats a broken new one, and disable auto-update until the next release.

Already stuck in the loop?

If every launch says "the next launch will retry", kill the process, delete the marker file (.update-incomplete or whatever it's called), and run the update manually from a clean shell. The marker is just a file. Deleting it breaks the loop.

Why this keeps happening

It's not one bug. It's the combination of Windows' file-locking semantics, updaters that report success before verifying, and self-updaters that can't see their own conflict. Each vendor is patching their own instance (hermes merged a fix that re-runs the updater via python.exe when it detects a shim launch; the Claude Code one was a missing npm publish), but the class of problem will keep showing up as long as tools replace their own running files on Windows.

So before you reinstall from scratch, try the five steps. In my experience, most of the time it's a locked file and a lying success message, not a corrupt install.

Sources: hermes-agent #89599, hermes-agent #93032, claude-code #88105, cline #13115

Cline Kills Long-Running Commands at 30 Seconds: Here's the Fix

MilkyWay008 — Mon, 24 Aug 2026 17:10:59 +0000

You're running a long command in Cline's Background Console, something like bit create or a big vitest suite, and right at the 30 second mark it dies with "Command timed out after 30000ms". Same command through the foreground terminal mode runs fine for up to an hour. Really annoying, and it's not your command's fault.

I dug into this after a user in issue #13246 couldn't get bit create to finish. The short version: there's a hard-coded 30 second timeout inside the SDK that Cline ships bundled with the extension, and the Background Console path uses it while the foreground path doesn't.

Why 30 seconds?

Cline's run_commands tool has two execution modes. The foreground one (vscodeTerminal) passes a 1 hour timeout to the SDK, straight from a constant that's literally 60 * 60 * 1000. The background path passes nothing, so the SDK falls back to its default. Two spots in the SDK source:

createShellTool does const timeoutMs = config.bashTimeoutMs ?? 30000;
the shell executor has timeoutMs = 30000 as a default, and that's what throws Command timed out after ${timeoutMs}ms

Both get compiled into the extension's dist/extension.js. I couldn't find any setting that controls it, which is probably why you've been hunting for one.

The fix: patch the bundle

Since there's no setting, the working workaround is patching the compiled extension. In your extensions folder (.vscode\extensions\saoudrizwan.claude-dev-<version>\next\dist\extension.js), do two replaces:

e.bashTimeoutMs??3e4 → e.bashTimeoutMs??36e5 (the tool factory default)
timeoutMs:r=3e4 → timeoutMs:r=36e5 (the shell executor default)

3e4 is 30000 ms, 36e5 is 3.6 million ms, which is one hour. Then reload VS Code. A minimal PowerShell version of that, run from the extensions folder:

$f = Get-ChildItem .\saoudrizwan.claude-dev-*\next\dist\extension.js |
  Sort-Object LastWriteTime -Descending | Select-Object -First 1
$c = Get-Content $f.FullName -Raw
$c = $c.Replace('e.bashTimeoutMs??3e4', 'e.bashTimeoutMs??36e5')
$c = $c.Replace('timeoutMs:r=3e4', 'timeoutMs:r=36e5')
Set-Content $f.FullName $c -NoNewline

Caveats, because there are always caveats. Those tokens are minified bundle output, so they can change between Cline releases. If a newer version doesn't match, grep for 3e4 and patch whatever the equivalent is. And any extension update will overwrite the patch, so either disable auto-update or keep the script around to re-run after updates.

The no-patch route

Don't want to touch the bundle? Run long jobs outside the Background Console. The regular terminal tool doesn't have this timeout, and on Windows you can fire a detached process and tail the log:

Start-Process cmd -ArgumentList '/c', 'your-long-command > C:\temp\job.log 2>&1' -WindowStyle Hidden

Then have Cline read the log file. Ugly, but it works, and it's what I'd do if patching the extension isn't your thing.

Upstream status

No official fix yet, as far as I can tell. The issue is still open, and a Cline team member suggested trying the "next" bundle override, which didn't help the reporter. So treat the patch as a stopgap. If you hit this, drop a comment on the issue and re-check it before you bother patching, since it could get fixed properly any day.

If your agent's background commands keep dying at exactly 30 seconds, it's not your shell, your script, or your machine. It's a hard-coded default inside the tool, and now you know exactly where it lives.

Your internet is capped at ~95 Mbps on a gigabit plan — the 100Mbps negotiation trap

MilkyWay008 — Sun, 23 Aug 2026 17:10:51 +0000

I've seen this exact post a hundred times: "I pay for 500 Mbps fiber and I only get 80." Usually the ISP gets blamed, sometimes the router. Most of the time it's neither. It's one stupid link in the chain quietly running at 100 Mbps.

The 95 Mbps tell

Here's the thing to understand first: 75-95 Mbps isn't a random slow speed. It's a signature. 100BASE-TX (Fast Ethernet) is a 100 Mbit/s link. Take off Ethernet/IP/TCP overhead and the practical ceiling lands right around 90-95 Mbps. So when your speed test keeps landing in that band no matter what, you're not getting a throttled 500 Mbps plan. You're getting a 100 Mbps link, and every packet is running through it.

No amount of ISP complaining fixes that. The link is the bottleneck, and the link is yours.

Why a link falls back to 100 Mbps

Gigabit (1000BASE-T) uses all four twisted pairs inside an Ethernet cable, bidirectionally. Fast Ethernet only needs two of them (pins 1-2 and 3-6). That's the whole story in one sentence:

A plain Cat5 cable (not Cat5e/6). Cat5 is only rated for 100 Mbps.
A damaged or bent pair.
A crimp or termination where only two pairs got wired. This is the big one. Lots of cheap patch cables and lazy punchdowns only carry two pairs, and they work fine at 100 Mbps, so nobody notices until they need gigabit.
A 100 Mbps-only LAN port. Many cheap ONTs (the fiber box on your wall) have exactly one gigabit port and the rest Fast Ethernet. Plug the router into the wrong one and you're capped at the wall, not the cable.
A marginal link that auto-negotiation quietly downgraded to 100/10, and it stays stuck until something forces a re-negotiation.

How to actually fix it

Don't start by calling the ISP. Work the ladder, in this order:

1. Read the negotiated link rate, not a speed test.
On Windows: Ctrl+Shift+Esc → Performance tab → Ethernet, look at the link speed. 100 Mbps vs 1.0 Gbps tells you everything. On the router side, the Deco app shows the WAN status. On most ONTs the port LED tells the story: amber/10-100M vs green/1G, check the sticker on your unit. If it says 100 Mbps anywhere, you found the bottleneck.

2. Swap the ONU→router cable.
Get a known-good Cat5e or Cat6 patch lead. If you're crimping your own, verify all 8 wires are terminated to T568A or T568B. All of them, not just the two pairs Fast Ethernet needs.

3. Use the gigabit port explicitly.
If your ONT has multiple LAN ports, make sure the router is in the gigabit one. Same on the router if it has a separate WAN port.

4. Isolate the sides.
Plug a PC directly into the ONT with the same cable and speed test. Getting 400+ Mbps? ONT and ISP are fine, the fault is in the router/Wi-Fi path. Still ~95? It's the cable or the ONT port.

5. Power-cycle both the ONT and the router after the cable swap.
Auto-negotiation doesn't always re-run on its own when you plug in a better cable. A stuck 100 Mbps link can stay stuck until the link drops and re-negotiates. Pull power on both, wait 30 seconds, plug back in.

6. Still capped?
Test a second known-good device to rule out a NIC pinned to 100 Mbps in the OS/driver settings. And don't force speed/duplex manually. Set everything to Auto Negotiation, or you can lock the link to 100 M for a different reason.

When it's not the cable

The ONT's LAN port itself is 100 Mbps-only. Sticker says so, you need a different port or a different ONT.
Your router's WAN port is 100 Mbps. (The Deco S7's three ports are gigabit, so if you're on one, that's not it.)
A degraded switch port in between.

All of these route back to the same question: what did the link negotiate?

The one thing to remember

A speed test tells you the result. The link rate tells you the cause. Gigabit plan capped at ~95? Don't chase the ISP. Go find the 100 Mbps link and fix the thing that's making it slow.

Why Ollama runs on CPU after an update: the missing sm_86 CUDA kernels

MilkyWay008 — Sat, 22 Aug 2026 17:05:59 +0000

Why Ollama runs on CPU after an update: the missing sm_86 CUDA kernels

You update Ollama, pull the model you use every day, and everything gets slower. Not broken, not erroring. Just slow. ollama ps says something like 12% CPU / 88% GPU, so you shrug and carry on. Then you open nvidia-smi mid-generation and see Ollama using 0 MiB of VRAM.

It's been running on CPU this whole time. Nobody told you.

This is what's happening to a lot of RTX 30-series owners after Ollama 0.32.14, and to people with A40/A6000/A10 cards too.

The symptom

The giveaway is buried in the server log. Somewhere in the noise:

msg="skipping CUDA device - compute capability not in compiled architectures"
device="NVIDIA RTX A6000" cc=860 archs="[750 890 1000 1200]"

cc=860 means your GPU is compute capability 8.6. The arch list is the set of architectures the bundled CUDA kernels were compiled for: 7.5 (RTX 20-series), 8.9 (RTX 40-series), 10.0 and 12.0. No 8.6. Your card isn't in the build.

Affected hardware: every sm_86 card. RTX 3090, 3080, 3070, 3060, plus the A40, A6000, A5000, A10 and friends. A big chunk of the people running local LLMs are on exactly these cards.

Why 0.32.14 made it worse

The missing sm_86 kernel isn't new. Older builds skipped the same arch. But they had a safety net: when the CUDA 13 kernels didn't cover the card, they fell back to the bundled CUDA 12 library, which does include sm_86. Same skip line, then:

msg="inference compute" ... library=CUDA compute=8.6

In 0.32.14 that fallback path broke. So instead of dropping to the CUDA 12 lib, the runner skips straight to library=cpu. Nothing errors, so you don't notice until the token rate starts to hurt.

The fix: pin back to a version with a working fallback

Upstream hasn't shipped a fix as of writing. The issue is open and the only maintainer reply so far is a request for more logs. The dependable move: pin to the last version where the CUDA 12 fallback worked, which for this one is 0.32.13.

Windows:

Uninstall Ollama.
Grab OllamaSetup.exe from the v0.32.13 release page on GitHub.
Install, and restart the ollama service if you run it as one.

Linux:

sudo systemctl stop ollama
# install the v0.32.13 .deb / .rpm / tarball from the releases page
sudo systemctl start ollama

Verify it's actually using the GPU

This is the step everyone skips, and honestly the reason this post exists. ollama ps can lie. It showed a GPU split while the GPU sat idle. The reliable check:

nvidia-smi during a generation. VRAM allocated to the ollama process, nonzero, means real GPU.
The log should show library=CUDA compute=8.6 again, not library=cpu.
Watch the tokens. A 27B model crawling at 7 tok/s is a CPU tell.

What not to waste time on

CUDA_VISIBLE_DEVICES=0. The GPU is visible. It's being skipped at the arch check, which is compile-time. No env var brings a missing arch back.
Forcing the CUDA 12 lib with OLLAMA_LOAD_LIBRARY. Some builds respect it, but in 0.32.14 the fallback path itself was the broken part, so don't count on it for this version.

The lesson that outlives this bug

After any update to a local-model stack (Ollama, llama.cpp, LM Studio, whatever), spend 30 seconds proving acceleration before you trust it. One nvidia-smi during a generation is the cheapest smoke test there is.

Silent degradation is worse than an error. An error tells you something's wrong. A silent CPU fallback just makes everything sluggish and you end up blaming the model.

And prebuilt-kernel coverage is decided at build time. When a release drops your GPU architecture, there's no flag that fixes it. Pin the last good version, watch the release notes, and move back up when the coverage returns.

The thread that started this: https://github.com/ollama/ollama/issues/17841