DEV Community: MilkyWay008

PowerShell autocompletes on every keystroke: it's PSReadLine predictive IntelliSense

MilkyWay008 — Tue, 13 Oct 2026 03:23:42 +0000

Somebody on r/powershell described it like this: they built a Win32 Intune package, and right after that their PowerShell window started completing things on every keystroke. clear bought them a few seconds of calm, then it came straight back. Only closing the window and opening a fresh one actually held.

I've run into this before. If I remember correctly, the package is almost never the culprit. It's PSReadLine......

What PSReadLine actually is

PSReadLine is the module that owns your interactive line editor. It isn't the shell and it isn't your terminal app. Every time you type at a PS> prompt, PSReadLine is what draws the line and decides what happens when you press Tab. It ships with Windows PowerShell 5.1 and PowerShell 7+, so it's always there whether you installed it or not.

Since PSReadLine 2.2.6, one of its features is on by default: predictive IntelliSense. That's the thing drawing ghost text ahead of your cursor and guessing your next command from history or from a plugin.

Version 2.1.0 introduced the feature in 2020, but with PredictionSource set to None. 2.2.6 flipped the default on for any terminal that supports virtual terminal sequences, which is roughly every terminal you'd be using today.

With PredictionViewStyle left at its default of InlineView, the guess gets drawn into the line you're typing, ahead of the cursor. Nothing is accepted, no Tab is pressed, but the line keeps redrawing every time the guess changes. That's the "it's typing for me" feeling. Switch to ListView and you also get a drop-down grid under the line, which is what makes some setups unusable.

Look before you change anything

Run these two and read three things: the version, PredictionSource, and PredictionViewStyle.

Get-PSReadLineOption | Select-Object PredictionSource, PredictionViewStyle
Get-Module PSReadLine | Select-Object Version, Path

If PredictionSource says History or Plugin and you never asked for predictions, you found it. Check the version too. Windows PowerShell 5.1 historically shipped PSReadLine 2.0.0, and a profile that imports a different copy can give you behaviour the docs don't describe. Worth listing what's installed side by side:

Get-Module PSReadLine -ListAvailable | Select-Object Version, Path

Turning it off

To stop it outright:

Set-PSReadLineOption -PredictionSource None

If you like history hints and just don't want the ghost text moving around on you, keep predictions and force the inline view:

Set-PSReadLineOption -PredictionSource History
Set-PSReadLineOption -PredictionViewStyle InlineView

Either way that only applies to the session you ran it in. Microsoft is explicit about it: to persist any of these options, they have to go in a profile script.

notepad $PROFILE
# add the line you want, e.g.
# Set-PSReadLineOption -PredictionSource None

If $PROFILE doesn't exist yet, create it first with New-Item -Path $PROFILE -ItemType File -Force. Otherwise you'll edit an empty nothing and wonder why nothing changed. Been there.

The second cause, which looks identical

There's an uglier variant with the same symptoms. PSReadLine caches where your line starts in the console buffer, along with the starting column. When the terminal gets resized, or the buffer is narrowed and then widened again, that anchor isn't always recalculated. From then on, every keystroke re-renders in the wrong column. That's the chaotic version where the line jumps around and you can't type at all.

Upstream PR #5190 spells it out: the edit anchor is never restored for the rest of that ReadLine call.

This is also why clear feels like a fix. Clear-Host wipes the visible display and leaves your session state alone, so the badly aligned drawing disappears. The bad anchor doesn't. Next keystroke, back to the mess.

For this class, clear the display, or resize the window once and press Enter for a fresh prompt, then update the module:

Update-Module PSReadLine -Force

You'll want a new shell after that.

Two isolation checks

If none of the above changes anything, PSReadLine probably isn't the problem, and something else is setting it. Start a shell without your profile:

pwsh -NoProfile

If typing is normal there, a profile script or another module is doing it. From there it's also worth trying the same session in Windows Terminal and in the old conhost window, since host-specific rendering bugs exist and they don't behave the same in both.

The honest caveats

The thread I pulled this from had zero replies and no accepted answer, so I can't tell you which of the two mechanisms hit that person. The Intune theory in the post doesn't hold up either. IntuneWinAppUtil.exe packs a folder into an .intunewin container. It doesn't read or write PSReadLine state, $PROFILE, or $PSModulePath. It could only matter indirectly, if a packaging script itself ran Set-PSReadLineOption or wrote a profile, and there's no evidence of that in the thread.

Treat the Intune angle as unproven. Treat "PSReadLine is drawing ghost text, or drawing in the wrong column" as the thing to check first. Both are documented upstream and both are fixable in about a minute.

Worth a try. Hope it helps.

0xC0000005 on Windows: how to find which module crashed

MilkyWay008 — Thu, 01 Oct 2026 17:16:52 +0000

Some app on your Windows box crashes. You search the crash code and get a wall of confident answers: update your graphics driver, run sfc /scannow, turn off XMP, reinstall Windows.

Most of that is a guess wearing a lab coat.

0xC0000005 is STATUS_ACCESS_VIOLATION. Windows defines it as the thread trying to read from or write to a virtual address for which it does not have the appropriate access. If your tool reports decimals instead of hex, the same code shows up as 3221225477. It's the most common crash code on Windows and the least useful one on its own, because almost anything can produce it.

Windows already wrote down what faulted. You just have to read the evidence in the right order.

Event 1000 names the module

Event Viewer, Windows Logs, Application, source Application Error, event ID 1000. I'd start there every time. If you'd rather not click through the UI:

Get-WinEvent -FilterHashtable @{LogName='Application';ProviderName='Application Error';Id=1000} -MaxEvents 20 |
  Select-Object TimeCreated,
    @{N='Exception';E={$_.Properties[6].Value}},
    @{N='Module';E={$_.Properties[3].Value}},
    @{N='PID';E={$_.Properties[8].Value}},
    @{N='ModulePath';E={$_.Properties[11].Value}},
    @{N='ReportId';E={$_.Properties[12].Value}}

The Module column is the whole point. 0xc0000005 in the Exception column confirms you're looking at an access violation and not something else wearing the same exit code.

One gotcha: when the faulting module is ntdll.dll or kernelbase.dll, you're usually looking at the messenger, not the culprit. Those are the most common places for a crash to surface because they do the memory work for everything else. The module you want is the last non-Microsoft one in the dump's stack.

Property order has been stable for years, but if your columns look shifted, open a single event's Details tab and read the field names instead of trusting the index numbers.

If there is no event 1000, turn dumps on

No Application Error entry means Windows Error Reporting never got a chance. Some apps die below the crash handler, usually very early in startup, and that absence is a clue in itself: it points at the GPU process or a native module load rather than application logic.

You can force dumps to be kept. From an admin shell:

$k = 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps'
New-Item -Path $k -Force
New-ItemProperty -Path $k -Name DumpFolder -PropertyType ExpandString -Value '%LOCALAPPDATA%\CrashDumps' -Force
New-ItemProperty -Path $k -Name DumpType -PropertyType DWord -Value 2 -Force
New-ItemProperty -Path $k -Name DumpCount -PropertyType DWord -Value 10 -Force

DumpType 2 is a full dump, which is what you want while the cause is still unknown. Dumps land in %LOCALAPPDATA%\CrashDumps; WER's own archives live under C:\ProgramData\Microsoft\Windows\WER\ReportArchive and ReportQueue. Then reproduce the crash.

Read the dump without installing Visual Studio

You don't need the IDE. Install just the "Debugging Tools for Windows" component from the Windows SDK, then point cdb at the dump:

cdb.exe -z "%LOCALAPPDATA%\CrashDumps\app.exe.1234.dmp" -c "!analyze -v; q"

Three things in that output matter. FAULTING_IP is the instruction that faulted. The EXCEPTION_RECORD gives you the ExceptionAddress and the code. STACK_TEXT is the call stack, and it names the module whose code was actually running. DEFAULT_BUCKET_ID is a loose classification you can search on to see if other people hit the same shape of crash.

The exception parameters also carry direction. ExceptionInformation[0] is 0 for a read, 1 for a write, 8 for an execute. A read violation means the thread dereferenced a pointer it couldn't read: garbage, or memory that was already freed. A write violation means something wrote where it had no business writing. Both are useful, but neither names a culprit without the stack.

Rule out hardware and drivers first

The System log tells you whether you're chasing software at all:

WHEA-Logger events 17 and 18 are corrected hardware errors; 19 is uncorrected. If those show up next to your crashes, stop and test the RAM with mdsched.exe (MemTest86 if you want a real answer). Memory and PCIe are the usual sources.
"Display driver amdwddmg stopped responding and has recovered" is a TDR, event 4101. That's the GPU and driver path, and it explains a lot of access violations in GPU-accelerated apps.
Kernel-Power 41 shows up after any unclean shutdown. Everyone reads it as a diagnosis. It isn't one. It's a marker that the machine went down hard, and on its own it names no cause.

Be suspicious of the confident answers

Two claims I'd flag, partly because I've repeated them myself:

The first: "the fault offset is always the same but the bad address changes, so it's bad RAM." That pattern does look more like corruption than a logic bug, and testing memory is a fair response to it. But it isn't documented as proof of anything. It can be bad RAM, a freed object, or a native module built against the wrong SDK, and only the dump separates those.

The second: "update the GPU driver, or switch the inference engine, and it goes away." Sometimes it does. While reading threads for this piece I found one where the suggested engine switch was tried by a second person and crashed for them too. Gone was the fix; the experiment stayed. Treat driver updates and engine switches as cheap things to try, not as advice you can hand someone else as an answer.

Same story with the launch-flag soup you'll find in older threads. --disable-gpu is a legitimate diagnostic because it moves rendering out of the GPU process. --no-sandbox is not a fix. It disables the sandbox. Chromium's own documentation says it's for testing, so don't leave it sitting in your daily configuration.

If the crash disappears after a clean boot, that's your answer: antivirus, overlays like RTSS or MSI Afterburner, and shell extensions all inject code into live processes, and all of them cause access violations.

The short version

0xC0000005 means "bad memory access". It does not mean bad RAM, and it doesn't mean the module named in the log is buggy. Event 1000 gets you the module, the dump gets you the function, and WHEA plus TDR tell you whether you're in hardware territory at all. Ten minutes of reading, most of it spent waiting for a dump to load.

I could be wrong about your specific crash. But if you're staring at this code with nowhere to start, the Event 1000 module name is the best first click you can make.

GPU offload says Max, but only 54 of 65 layers loaded: how to check where your model actually runs

MilkyWay008 — Wed, 30 Sep 2026 17:10:23 +0000

A 27B model at Q4 was generating 12-18 tokens per second on an RTX 3090. Same model, same settings a week earlier, it was doing 60-70. Nothing in the app looked broken. The model config still said GPU Offload: Max.

That's the trap. Max doesn't mean all layers on the GPU. It means as many as the app's size estimate thinks will fit. When that estimate comes out pessimistic, the loader quietly leaves layers on the CPU, and you pay for it on every token instead of noticing it once.

Here's how to check what actually happened, and what to try.

The load log is the source of truth, not the dropdown

LM Studio writes a log per model load. They live under your user profile in .lmstudio. The paths I've seen quoted are %USERPROFILE%\.lmstudio\logs\ for the app log and %USERPROFILE%\.lmstudio\server-logs\ for the per-load server log, so have a poke around if yours sit somewhere else.

Load a model, open the newest log, and look for this pair:

Limit weight offload to dedicated GPU Memory: ON
Model load size estimate with adjusted num offload layers '54'

"Adjusted" is the word doing the damage. The setting asked for Max. The estimator adjusted it down to 54 because its model of your VRAM said the rest wouldn't fit.

Then llama.cpp prints the final answer on its own line:

offloaded 54/65 layers to GPU

If both numbers match, everything landed. If they don't, you're running a hybrid and the CPU is handling part of every token. On a 27B that's the difference between roughly 45 tokens per second and 15.

The check that doesn't need logs

Watch GPU and CPU utilization while the model generates.

Full offload looks like GPU utilization pinned high (the reporter measured around 97%) with the CPU mostly idle. Partial offload looks like low, spiky GPU utilization, a busy CPU, and throughput down by 2-3x. If it looks like the second case while the settings say Max, the estimator is your suspect.

Why the estimate trims layers at all

The machinery shows up clearly in another report in the same tracker. With the VRAM cap armed, the estimator runs and adjusts. With the cap off, it skips the adjustment step entirely:

[LM Studio] Model load size estimate with raw num offload layers 'max' and context length '8192'
[LM Studio] Strict GPU VRAM cap is OFF: GPU offload layers will not be checked for adjustment
[LM Studio] Resolved GPU config options:   Num Offload Layers: max

So the setting behind that first log line, something like "Limit weight offload to dedicated GPU memory" in the load settings, is what arms the trimming. It isn't a silly feature. It stops you from requesting more layers than the card can hold and getting worse performance for it. It just isn't always right.

What to try, in order

Switch the runtime backend. This was the change that reliably worked for the reporter. The engine was set to the CUDA 12 runtime; switching to the plain CUDA runtime, or to Vulkan, restored full offload. Throughput went from 12-18 tok/s to 41.9-45.4 tok/s at roughly 97% GPU utilization, across four different 27B models and a range of CUDA 12 runtime versions. A dropdown change for about a 3x speedup.
Set an explicit layer count instead of Max, so nothing is left to the estimator. Unload and reload, then read the log line again. If you set 65 and the log still says 54, the trimming is happening anyway and you're back to step 1.
Reduce the context length. The KV cache for a long context eats into the budget the estimator is working with, so a shorter context can leave more room for weights. Worth trying, though the reporter found it didn't reliably stop the behaviour.
From the CLI: lms load <model> --gpu max (or off, or a fraction like 0.5), --context-length to cap context, and --estimate-only to see what the loader plans before you commit to the load. Those are in LM Studio's CLI docs.

The honest part

The CUDA 12 trimming is an open issue with no official fix as of late September 2026, so everything above is diagnosis plus a workaround, not a patch. Nobody has confirmed why the CUDA 12 path over-trims while the regular CUDA and Vulkan runtimes don't. The running theory in the thread is that the CUDA 12 build reserves more memory for graph and KV buffers, which makes the estimate come out larger, but that's a commenter's theory rather than a maintainer's finding. Treat it as a hypothesis.

Worth saying out loud too: partial offload is sometimes the correct outcome. If your card genuinely can't hold the model, turning the cap off doesn't create VRAM. It just lets you overcommit, and overcommitting usually performs worse than a clean split.

One related pattern, because it's the same class of problem on AMD hardware: an RX 6900 XT (RDNA2) on Windows can fail outright with "RDNA2 not supported with the ROCm version you are using" when the ROCm engine gets selected, while Vulkan works fine on the same card. Different message, same lesson. The backend picker matters more than the offload slider, so bisect the runtime before changing anything else.

If you remember one thing from this: after loading a model, grep the load log for the offload count. Max is a request, not a receipt.

The source report, with the full logs, is here: https://github.com/lmstudio-ai/lmstudio-bug-tracker/issues/2312

[ASN1] nested asn1 error on Windows: one bad cert in the store breaks every Python tool

MilkyWay008 — Tue, 29 Sep 2026 17:17:35 +0000

I was scrolling through bug reports a while back and one of them made me stop: a Python tool that dies on import with ssl.SSLError: [ASN1] nested asn1 error. Machine was fine, network was fine, code was fine...... the user had just upgraded the app. Rolling back fixed it, which is the sort of detail that sends you hunting in the wrong place for an hour.

I dug into it, and as far as I can tell the app was never the problem. One certificate sitting in the Windows certificate store was.

What is actually blowing up

On Windows, CPython's ssl module does not just read a bundled CA file. When something asks for a default SSL context, it walks the Windows certificate stores and collects the certs into one big buffer. Here is the code from Lib/ssl.py:

def _load_windows_store_certs(self, storename, purpose):
    certs = bytearray()
    try:
        for cert, encoding, trust in enum_certificates(storename):
            # CA certs are never PKCS#7 encoded
            if encoding == "x509_asn":
                if trust is True or purpose.oid in trust:
                    certs.extend(cert)
    except PermissionError:
        warnings.warn("unable to enumerate Windows certificate store")
    if certs:
        self.load_verify_locations(cadata=certs)
    return certs

Read that last part again. Every cert goes into certs, and then the whole pile is handed to load_verify_locations in a single call. The stores it walks are ('CA', 'ROOT').

So if one cert in that pile is malformed, the DER parse fails for the entire buffer:

ssl.SSLError: [ASN1] nested asn1 error

The bad one might be the 45th out of 45. The rest are perfectly good. Doesn't matter. The call throws, the context never gets built, and whichever import or TLS call comes first is the one that dies. Your code never gets a say in it.

Depending on how the bytes are mangled you may get a different message for the same underlying problem: SSLError(0, 'not enough data: cadata does not contain a certificate'). I hit both while testing.

I reproduced it in about 20 lines

I didn't want to take this one on faith, so I ran it. Enumerating the ROOT store on my Windows 11 box gave 45 certs, 48,107 bytes of DER. Loaded whole, everything is happy. Then I flipped a single byte inside one certificate and loaded the exact same buffer:

python: 3.11.15 | openssl: OpenSSL 3.5.6
ROOT store: 45 certs, 48107 bytes DER
baseline load_verify_locations(all store certs) -> OK
REPRO: 1 corrupted cert among 45 valid -> SSLError: [ASN1] nested asn1 error (_ssl.c:4057)

One byte. That is the whole bug. If you want to poke at it on your own machine:

import ssl
from _ssl import enum_certificates

certs = [c for c, enc, trust in enum_certificates("ROOT") if enc == "x509_asn"]
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ctx.load_verify_locations(cadata=b"".join(certs))   # works ... unless one cert is bad

Why SSL_CERT_FILE does not save you here

The instinct is to point Python at a known-good bundle and move on. On Windows that does not stop the scan, because of the order these things run in. SSLContext.load_default_certs walks the stores first and only afterwards calls set_default_verify_paths(), which is where SSL_CERT_FILE and SSL_CERT_DIR are actually consulted:

def load_default_certs(self, purpose=Purpose.SERVER_AUTH):
    ...
    if sys.platform == "win32":
        for storename in self._windows_cert_stores:
            self._load_windows_store_certs(storename, purpose)
    self.set_default_verify_paths()

The bad cert blows up the buffer before your environment variable is ever read. Same story for any tool that builds its context with a bare ssl.create_default_context().

I'm reading this off CPython 3.11 and 3.12. If you're on something newer, .../Lib/ssl.py is right there on disk. The ordering has been tweaked between releases, so check yours rather than trusting my summary of it.

Find the bad cert

This part is read-only and quick. PowerShell 5.1, no admin needed:

# try to re-parse every cert in the root stores as X.509 DER
$stores = @('Cert:\LocalMachine\Root', 'Cert:\CurrentUser\Root', 'Cert:\LocalMachine\CA')
foreach ($s in $stores) {
    if (-not (Test-Path $s)) { continue }
    Get-ChildItem $s -ErrorAction SilentlyContinue | ForEach-Object {
        try   { $null = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($_.RawData) }
        catch { "BAD  {0}  {1}  {2}" -f $s, $_.Thumbprint, $_.Subject }
    }
}

Whatever the catch prints is your suspect. On a healthy machine you get nothing back, which is exactly what happened when I ran it here.

Export before you delete anything:

$c = Get-ChildItem Cert:\LocalMachine\Root\<THUMBPRINT>
Export-Certificate -Cert $c -FilePath "$env:USERPROFILE\Desktop\suspect.cer"

Then remove it, either through certlm.msc (Trusted Root Certification Authorities, find the thumbprint, delete) or:

Remove-Item -Path Cert:\LocalMachine\Root\<THUMBPRINT>   # admin shell

One caveat that matters. If the cert turns out to be your company root for TLS inspection, do not delete it, re-import it properly. A half-imported corporate root will break internal TLS the moment it's gone, and now you have two problems instead of one.

Where do malformed certs come from anyway? Usually a truncated import by an installer, an endpoint agent or AV product, an old tool that wrote DER where the store wanted PEM, or someone hand-copying a root out of a browser.

If you cannot touch the store, skip the scan

For code you own, pass an explicit CA source. Any of cafile, capath or cadata takes a different branch, so load_default_certs never runs:

import ssl, certifi
ctx = ssl.create_default_context(cafile=certifi.where())   # store is never scanned

# from Lib/ssl.py:
#   if cafile or capath or cadata:
#       context.load_verify_locations(cafile, capath, cadata)
#   elif context.verify_mode != CERT_NONE:
#       context.load_default_certs(purpose)

For tools you don't own, it's the same idea expressed as whatever config that tool reads. This is also the answer to the other half of the problem that kept showing up in those reports. Behind a TLS-inspecting proxy, exporting your corporate CA to one tool does nothing for the next tool, because each one has its own knob.

Tool	Setting
Python `ssl`	`SSL_CERT_FILE`, `SSL_CERT_DIR`
requests	`REQUESTS_CA_BUNDLE`, `CURL_CA_BUNDLE`
pip	`PIP_CERT`, or `--cert`
Node.js	`NODE_EXTRA_CA_CERTS` (PEM, appended to the bundled roots at launch)
npm	`npm config set cafile <path>`
curl	`CURL_CA_BUNDLE`, `--cacert`
git	`GIT_SSL_CAINFO`, `git config --global http.sslCAInfo <path>`
uv	`SSL_CERT_FILE`, `SSL_CERT_DIR`, plus `UV_NATIVE_TLS` if you want the platform store
AWS CLI / boto3	`AWS_CA_BUNDLE`

And please don't "fix" this with verify=False or curl -k. That hides the error and hands the problem to whoever reads your traffic next.

The bit worth remembering

A shared trust store is a single point of failure. One bad byte in an entry you never put there takes down every process that asks for a default context, and the error lands in whichever tool happened to load first. The thing that crashes is rarely the thing that is broken.

I can be wrong about your specific machine, but if the traceback points at _load_windows_store_certs, run the scan above before you downgrade anything. Hope this helps.

Method invocation is supported only on core types in this language mode: what it means and how to fix it

MilkyWay008 — Tue, 29 Sep 2026 02:50:39 +0000

You run one command in your agent CLI. It works. Then a wall of red shows up anyway:

Cannot invoke the method. Method invocation is supported only on core types in this language mode.
    + FullyQualifiedErrorId : MethodInvocationNotSupportedInConstrainedLanguage

Exit code 0. The thing you asked for actually happened. So what's complaining, and why does it keep complaining on every single command?

I keep seeing this one in issue trackers, most recently for Copilot CLI on a domain-joined Windows 11 machine. The same error shows up in other tools too, anywhere a CLI shells out to PowerShell. If I remember correctly, here's the mechanism......

What's actually happening

PowerShell doesn't decide on its own to restrict you. When Windows detects an application control policy, either AppLocker or WDAC (Microsoft now calls that App Control for Business), PowerShell starts the session in ConstrainedLanguage mode. It's documented in about_Language_Modes if you want the source.

Constrained language isn't "no PowerShell". Cmdlets still run. Loops, ifs, functions, strings, all of that works. What changes is .NET method calls: they're only allowed on a short allow-list of core types, and everything else throws.

The tool's wrapper script usually ends like this:

$host.SetShouldExit($LASTEXITCODE)

$host is an InternalHost object, which isn't a core type, so that line fails. It's also the last line of the epilogue, which means it fails after your actual command already ran and returned 0. The cleanup path is complaining, not the work.

One JetBrains user hit the same class of thing from a second call, $Error.RemoveAt(0).

Confirm it in one line

Cmdlets aren't blocked under constrained language, so the diagnostics themselves work fine:

$ExecutionContext.SessionState.LanguageMode

If that prints ConstrainedLanguage, you found it. Then work out what's enforcing it:

Get-AppLockerPolicy -Effective -Xml

Non-empty output means AppLocker is the enforcer. For WDAC the logs are the tell. In Event Viewer:

Applications and Services Logs > Microsoft > Windows > AppLocker > MSI and Script: 8007 is a script blocked, 8006 is audit only, 8005 is allowed.
CodeIntegrity > Operational: 3076 (audit) and 3077 (blocked) mean WDAC is enforcing.
PowerShell > Operational: entries state that the session ran in ConstrainedLanguage.

What actually fixes it

Two levels here, and I want to be careful about which one I'm putting my name behind.

The real fix is a policy exception, and it is documented. Scripts a policy allows run in FullLanguage even when the session is constrained. So the tool's wrapper scripts need to be in the allow list: a WDAC file or signer rule covering the app's payload, or the Managed Installer option if it's deployed through Intune or ConfigMgr. On the AppLocker side, a script rule exception for the tool's path or publisher. That's a change request rather than a workaround, and I know it can take a week to land. Raise it anyway, because it's the only version of this that survives the next update.

For today, stop routing through PowerShell. Most agent CLIs let you choose which shell their shell tool uses. Point it at cmd.exe or bash and the wrapper never runs. That's what people in the Copilot CLI thread reported working. One thing that does not work: setting VS Code's terminal.integrated.automationProfile.windows. Someone tested it and it changed nothing, because the CLI spawns its own shell rather than going through the integrated terminal. Passing that on so you don't burn an afternoon on the same red herring.

What not to do

You'll find these recommended. Don't.

Flipping __PSLockDownPolicy under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment to turn constrained mode off.
powershell -Version 2, or launching from a whitelisted directory to dodge the policy.
Smuggling the command through an allowed helper with encoded arguments.

All of those defeat application control, which is usually there because somebody's audit depends on it. Getting your machine quarantined over a red error message that wasn't even breaking anything is a bad trade. And if the error is pure noise and the command exits 0, letting it scroll past while your ticket sits in the queue is a legitimate option. It's ugly, but it's honest.

The general lesson

If a PowerShell script works on your box and fails on a managed one, check the language mode before you rewrite any logic. Constrained language also hits Add-Type, most COM object use, and plenty of method calls you'd never think twice about. The error text names the method it blocked, which is a decent tell that you're hitting the mode rather than a bug in your script.

And if you maintain one of these CLIs, the fix on your side is small. Use the exit keyword instead of $host.SetShouldExit(), or guard that call behind a language-mode check. The Copilot CLI issue is still open with no merged fix that I could find, so in the meantime it's the shell switch plus a ticket.

The language mode check takes ten seconds, so it's cheap to rule in or out. I could be wrong about the details for your particular tool, but I hope this saves somebody an afternoon.

MongoDB's 16MB document limit: how to find the doc that kills your agent run

MilkyWay008 — Sun, 27 Sep 2026 17:15:01 +0000

One of the agents I look after keeps its state in MongoDB, and a few weeks back it started doing the thing I dislike most: nothing. No stack trace, no failed HTTP call to point at. The run just sat there while the UI kept spinning.

There was an error, all right. It wasn't in the app, it was in the database.

A Mastra user hit the same wall in issue #21412. Long DurableAgent runs, MongoDB storage, workflow-snapshots collection. Their snapshot document grew past MongoDB's per-document size limit, the write got rejected, the snapshot flipped to failed, the framework deleted it, and the stream had nowhere left to go. That thread closed as resolved in a later release, but the trap underneath it isn't Mastra's. It belongs to MongoDB, and it's waiting for anyone who stores a growing conversation inside a single document.

So here's the limit, how to find the document about to cross it, and how I restructure before it happens.

The limit itself

MongoDB's docs are blunt about this one. The maximum BSON document size is 16 mebibytes, 16777216 bytes, and it's described as a hard limit. The server reports the value as maxBsonObjectSize in the hello command:

db.runCommand({ hello: 1 }).maxBsonObjectSize

You can't raise it. No server flag, no mongod option, no storage-engine setting, and no compression switch that changes the encoded size. The constant sits in the server source as BSONObjMaxInternalSize. Once the encoded BSON crosses that line the whole write is rejected: the document isn't truncated, it isn't split, and nothing partial lands in the collection.

Why agent state walks straight into it

16MB sounds roomy until you look at what an agent appends every turn. The user message, the assistant message, every tool call, every tool result, and usually a copy of all of it inside the stored history. Tool results are the fat ones: a read_file on a 400KB log, a JSON API response, an HTML page, a base64 blob.

A few hundred turns of that and you're not at 16MB because somebody wrote bad code. You're there because the data is genuinely big, and nothing in the pipeline was ever told to stop growing.

The failure is quieter than it should be. The snapshot write fails, the framework moves on, and the symptom you actually get to see is a stream that stops.

Finding the document before it kills a run

Open mongosh against the database and size the documents. $bsonSize is the aggregation expression for exactly this, and it works on $$ROOT:

db.workflow_snapshots.aggregate([
  { $project: { sizeMB: { $divide: [ { $bsonSize: "$$ROOT" }, 1024 * 1024 ] } } },
  { $sort: { sizeMB: -1 } },
  { $limit: 10 }
])

That's your ten fattest documents. To see which field is eating the space, unwind the document into fields and size each one:

db.workflow_snapshots.aggregate([
  { $project: { fields: { $objectToArray: "$$ROOT" } } },
  { $unwind: "$fields" },
  { $project: { field: "$fields.k", bytes: { $bsonSize: "$fields.v" } } },
  { $sort: { bytes: -1 } },
  { $limit: 15 }
])

The top of that list is usually what you'd expect: the message history, then whatever tool output got stored next to it. If you only want one document's size from the shell, Object.bsonsize(doc) is the shortcut.

Fixing it

Keep the growing array out of the document that has to stay small. Let the snapshot record hold state, not the transcript. Messages go in their own collection keyed by session, and the snapshot keeps a reference plus a turn count.

Cap the array as you append to it. $push with $each and a negative $slice keeps only the newest entries, atomically, in a single update:

db.sessions.updateOne(
  { _id: sessionId },
  { $push: { history: { $each: [ message ], $slice: -200 } } }
)

A negative number means "keep the last N", per the $slice modifier docs. $slice also requires $each. On its own it gets silently skipped, which is a fine way to spend an afternoon wondering why your array never shrinks.

Move the blobs out. If a tool result is a file you never query into, store the blob and keep the id. GridFS is built for that: it splits a file into chunks across fs.files and fs.chunks, 255KiB each by default, which is how it sidesteps the 16MB cap. Its own docs say that if your files are all under 16MB, just store them in a document. So reach for it when the thing really is bigger than a document should be, not as a general message store.

Set retention. TTL indexes delete whole documents once a date field ages out. The background task runs every 60 seconds, and TTL indexes are single-field only. Great for old sessions. Useless for trimming an array inside a live document.

What doesn't work

Raising the limit. It's hard-coded, and searching for a flag wastes a day.

A TTL index on an embedded array field, hoping it keeps the last N messages. TTL expires documents, not array elements, and it can't be compound.

GridFS as your conversation store. It gets around the limit honestly, one chunk per document, but it's a file API. Rebuilding a chat from chunk documents is not a thing you want to be doing at 2am.

Capped collections as a fix for a growing array. A capped collection is an append-only log, and it does nothing for the snapshot document that keeps getting updated.

The named data-modeling patterns (bucket, subset, extended reference) are the textbook answer, and the bucket pattern is the one I'd look at for time-sliced history. Fair warning: the docs restructured recently and the old building-patterns pages now 404, so I couldn't re-check the wording before writing this.

The honest part

I haven't run this against Mastra itself, so I'm going on the reporter's account plus what the database does. The $bsonSize pipeline is verified against MongoDB's operator docs. The per-field version is composed from documented stages and I haven't run that exact three-stage form end to end, so paste it into a copy first.

I also couldn't confirm the exact error string a current server returns when a document overflows. It will name the 16777216-byte limit and it will land at write time. If you're grepping logs for a magic phrase, stop and size the documents instead. It's a two-minute query and it tells you the truth.

Worth a look at your own state collection even if nothing has died yet. The document sitting at 12MB today is the one that takes a run down next week.

fetch-pack: invalid index-pack output, and a .git folder that ballooned to 6 GB

MilkyWay008 — Sat, 26 Sep 2026 17:19:05 +0000

If you have ever wrapped git fetch in a timeout, cancelled a clone halfway, or shut the laptop lid mid-pull, you may already be carrying this bug around. Nothing warns you. Git just starts acting strange weeks later.

I ran into it while following a bug report on a self-updating app that ran git fetch with a 10 second timeout and swallowed every error with except Exception: pass (which is its own lesson). On the reporter's machine the repo had grown to 6 GB, update checks hung for 30+ seconds, and fetches were failing with a pile of different messages:

fetch-pack: invalid index-pack output
Could not read <sha>
invalid reflog entry
HTTP 429 on ls-remote (this one is usually a red herring)

Three different symptoms, one cause, and it is not corruption.......

What git leaves behind when you kill a fetch

Git does not write an incoming pack straight to its final filename. builtin/index-pack.c writes the pack to a temp path inside .git/objects/pack/ named tmp_pack_XXXXXX, and only renames it to pack-<hash>.pack after the transfer completes and the index has been built (rename_tmp_packfile()). Index files get the same treatment as tmp_idx_*.

Kill the process between those two moments and the rename never happens. You are left with tmp_pack_XXXXXX in the pack directory, usually marked read-only (0444).

Git will never treat that file as a pack. It is not indexed, not counted as a pack, and not cleaned up by itself. It just sits there taking up disk. In the report I was following, repeated failed update checks had pushed the repo to 6 GB. I reproduced it on Windows in a scratch repo: killed a clone mid-transfer and a 264 MB read-only tmp_pack stayed behind.

Git will show you these if you know which field to look at:

$ git count-objects -vH
...
garbage: 1
size-garbage: 264.00 MiB

garbage and size-garbage are where orphaned temp files land. I had never paid attention to that field either.

Why gc doesn't clean it up

This is the part that made me put the keyboard down for a minute. Plain git gc does not remove them. Neither does git repack -ad. git fsck --full only prints a warning about them. I tested all three on scratch repos and the temp files survived every one.

The reason is the prune grace period. The thing that actually deletes tmp_* files under objects/ and objects/pack/ is git prune (remove_temporary_files() in builtin/prune.c). But git gc runs prune with gc.pruneExpire, and that defaults to 2 weeks. A temp file written five minutes ago is younger than the grace period, so gc looks straight past it.

So files created minutes ago get ignored, and files that get ignored stay forever if you keep re-running a failing fetch. That is the whole trap.

The fix

Nothing here touches your commits, but do it when nothing else is using the repo.

1st, confirm no git process is running. On Windows:

tasklist | grep -i git

A live fetch plus a prune is the one combination that can genuinely damage a healthy repo.

2nd, look at what you have:

du -sh .git
find .git/objects/pack -name 'tmp_*' -ls

3rd, check whether this is only orphans or something worse:

git fsck --full

4th, if fsck only reports garbage (no missing objects, no broken links), delete the orphans:

git prune --expire=now

git gc --prune=now does the same job. The --prune=now is the part that matters; without it you get the 2 week grace period back and nothing gets removed.

On Windows those temp files are read-only, so del in cmd will refuse until you run attrib -R .git\objects\pack\tmp_* first. In Git Bash, rm -f .git/objects/pack/tmp_* is fine. PowerShell's Remove-Item -Force works too. I tried all three.

Finally, confirm and move on:

git count-objects -vH
git fetch

size-garbage should be 0 and the fetch should stop complaining.

When it is actually corruption

git fsck --full is the line in the sand. If it keeps reporting missing blob/tree/commit, broken link, or invalid reflog entry <sha>, then objects your refs point at are gone, and pruning will not bring them back. That is the re-clone case:

git clone --depth 1 <url> newdir

A warning about one common piece of advice: git reflog expire --expire-unreachable=now --all gets recommended a lot here. It does silence reflog complaints, but it permanently drops your undo history. If all you have is orphaned temp files, you do not need it. Skip it.

Two more things I would avoid. Do not run git gc --prune=now --aggressive on a repo you have not fsck'd yet, and do not blame your network for a 429 on ls-remote until the temp files are gone and you have retried once.

If you build tools that call git

The app-side fix that went in for the bug I was following was a cleanup step on the fetch timeout path: look for stale tmp_pack_*, remove the ones older than 10 minutes, and report "update check failed" instead of hanging silently. If your tool shells out to git fetch with a timeout, that is worth copying. A timeout that kills the child and walks away leaves a small landmine for the next run, and the next run does not know about it.

Your mileage will vary with repo size and git version (I tested on Windows with git 2.54). I have only seen this on machines where fetches were being killed rather than failing cleanly, so there may be other paths into the same state. But if .git is enormous and fetches throw invalid index-pack output, check the pack directory before you nuke anything.

Source thread: NousResearch/hermes-agent#93732

Why your CLI says you're not logged in on a headless Linux server

MilkyWay008 — Fri, 25 Sep 2026 17:07:02 +0000

You finish the OAuth flow on a fresh VPS. The browser says success. The CLI writes a token file with an expiry three weeks out. Then it hangs on "Verifying your account", or tells you that you are not logged in.

If the token file is right there and still valid, you are probably not fighting the login. You are fighting the credential store the CLI looks in first, which on Linux is the desktop secret service. On a headless box that service is not running.

What the CLI is actually asking for

Most cross-platform CLIs (Gemini CLI, gh, gcloud, the agent CLIs, anything built on keytar or libsecret) do not keep OAuth tokens in a plain file. They hand them to the OS secret store:

Linux: libsecret, which talks to org.freedesktop.secrets over D-Bus, implemented by gnome-keyring or KWallet
macOS: Keychain
Windows: Credential Manager

On a desktop this is invisible. Your login session starts a session bus and unlocks the keyring, so reads and writes just work.

Over SSH as root on a cloud image, none of that exists. No session bus means DBUS_SESSION_BUS_ADDRESS is empty. No daemon means nothing is registered on the bus. And even when gnome-keyring is installed, it is usually locked, because unlocking happens through PAM at a graphical login that never took place.

The part that wastes an evening: when the keyring call throws, most CLIs catch the exception and print the same message they print for a missing token. "You are not logged in." You are logged in. The file is there. The process just cannot reach its credential store. I have seen that exact line in agent CLI logs sitting next to a token file with a valid future expiry.

Three commands to confirm it

echo "$DBUS_SESSION_BUS_ADDRESS"     # empty means no session bus
secret-tool lookup service test      # not found / cannot connect means no secret service
timedatectl status                   # check the clock while you are here

If the first is empty and the second fails, you have found your problem.

The fix

Install the pieces, then give the CLI a session bus with an unlocked keyring:

sudo apt update
sudo apt install -y dbus-x11 gnome-keyring libsecret-tools

Package names vary by distro, so a quick apt-cache search secret-tool (or your distro's equivalent) is worth doing before you trust that list. On Fedora and RHEL the packages are dbus-x11, gnome-keyring and libsecret.

Then run the login inside a private session bus, with the keyring unlocked from stdin:

dbus-run-session -- bash -c '
  printf %s "$KEYRING_PW" | gnome-keyring-daemon --unlock --components=secrets
  exec your-cli login
'

dbus-run-session starts a bus for that one command tree. gnome-keyring-daemon --unlock reads the password from stdin and exports GNOME_KEYRING_CONTROL and GNOME_KEYRING_PID for its children. The CLI then finds a working secret service, stores the token, and stops pretending you never logged in.

Confirm the store is reachable:

printf 'hunter2' | secret-tool store --label=test svc key
secret-tool lookup svc key

If lookup prints the value back, you are good.

Two caveats I would rather say out loud. Running as root is the worst case: root's session does not get a PAM keyring unlock, /run/user/0 may have no bus at all, and some backends refuse root outright. Where you can, create a normal user, run loginctl enable-linger <user>, and do the login as that user, so a systemd user session keeps a bus alive between SSH sessions. On a long-lived server you want that bus to outlive your SSH connection, otherwise the next cron run starts from scratch.

If the host is disposable and you only need it working now, a keyring created with an empty password is an option. It is still a secret store, but it is one that anyone with the file can open. I would treat it as a last resort.

The other thing that breaks login right after a login: the clock

Different cause, same symptom family. Refresh tokens are validated against server time. A VM or container whose clock is minutes off gets invalid_grant on refresh even with a perfectly good keyring, which looks exactly like a successful OAuth login followed by an immediate auth failure. There is a gemini-cli issue on Ubuntu reporting invalid_grant with exit code 41, where clock skew and stale credentials are among the usual suspects.

timedatectl status
sudo timedatectl set-ntp true

Sometimes there is a token env var and you can skip all of this

Headless auth is common enough that plenty of tools ship an escape hatch:

gh: GH_TOKEN bypasses keyring storage entirely
gcloud: --no-launch-browser, with CLOUDSDK_CONFIG controlling where credentials live
docker: credential helpers, or a plain config file

Thirty seconds with your-cli --help | grep -i token is worth it before you install a keyring stack. If the tool documents a file-based credential store, use it instead.

What not to do

Do not export an invented DBUS_SESSION_BUS_ADDRESS. The bus has to exist. Pointing at a socket that is not there gives you a different error and a longer afternoon.
Do not put the token or the keyring password in argv or a shell env var on a shared box. /proc and CI logs are not a secret store.
Do not assume a token file means an authenticated session. That assumption is the whole bug.

None of this is exotic. It is a desktop assumption leaking into server tooling, and it costs people an evening because the error message points at the wrong thing. Worth a try: read the CLI's own log for the word keyring, secret, or token source before you change anything. If a keyring error is in there, the steps above are the path. If it is not, it may genuinely be a bad credential, and the auth logs are the next stop.

Your Windows app auto-updated and now it won't open: what 0x80073D02 means

MilkyWay008 — Thu, 24 Sep 2026 17:06:19 +0000

A few weeks ago an app on my machine updated itself, quit, and then never came back. The desktop icon did nothing. Nothing showed up under Apps in Task Manager. The only clue was a dialog about apps needing to be closed and an error code: 0x80073D02.

If you've run into this with Claude Desktop, Codex, or any other app that ships as an MSIX package, here's the short version: it's usually not a corrupted install, and reinstalling is often the slowest way out. It's a package swap that didn't finish, and you can usually clear it in a couple of minutes.

An MSIX update is a package swap, not a patch

When one of these apps updates, Windows stages the new files, adds the package, then registers it for your user account.

Staging and adding are file operations. Register is the step that touches your user's state, and it comes with a hard requirement: nothing from the old version can still be running. If something is, the deployment service returns 0x80073D02, which is ERROR_PACKAGES_IN_USE. Microsoft's wording is that the package's resources are "currently in use".

That's why the failure shows up at the very end of an update that looked fine right up to the last step.

The updater quits the app, not everything the app started

The shutdown API Windows gives packaged apps covers the processes belonging to the package. For Claude Desktop, that's the Claude.exe set. It does not cover the helpers the app launched that carry no package identity: a bundled CLI running out of %APPDATA%, node.exe processes from MCP servers, a native messaging host for browser integration, a Python process holding an stdio MCP connection.

One surviving process is enough to pin the package and abort Register.

The annoying part: those helpers don't show under the app's name in Task Manager's Processes tab, because that tab groups by app identity. Switch to the Details tab and sort by name.

Packaged services cause the same thing. Some apps install one, and Claude Desktop's is called CoworkVMService. It's marked AUTO_START, so a repair flow that stops it to free the package gets it back a few seconds later, mid-servicing, and Register fails again. Disabling it isn't an option either: Set-Service -StartupType Disabled returns Access denied, because the service's DACL only grants that right to the OS deployment service. That one is by design.

Finding what's holding the package

Start with the package and where it lives:

Get-AppxPackage -Name "*Claude*" |
  Select-Object Name, PackageFullName, InstallLocation, Status

Now the part that matters. Get-Process -Name claude only matches on name, which is why it misses the leftovers. Match on executable path instead:

Get-CimInstance Win32_Process |
  Where-Object { $_.ExecutablePath -like "$env:LOCALAPPDATA\Packages\Claude_*" } |
  Select-Object ProcessId, Name, ExecutablePath

And check whether a packaged service is in the picture:

Get-Service CoworkVMService | Select-Object Name, Status, StartType

The fix, cheapest attempt first

Kill the leftovers, then relaunch.

Get-Process claude, cowork-svc -ErrorAction SilentlyContinue | Stop-Process -Force

If name matching misses (it often does), take the PIDs from the path query above and stop those. Several reporters said this alone sorted it, on the same machine, repeatedly.

Stop the service, kill, re-register the package yourself.

Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
Get-Process claude, cowork-svc -ErrorAction SilentlyContinue | Stop-Process -Force

$pkg = Get-AppxPackage -Name "*Claude*"
Add-AppxPackage -DisableDevelopmentMode -Register "$($pkg.InstallLocation)\AppxManifest.xml"

That's roughly what Settings > Apps > Advanced options > Repair does under the hood, minus the part where AUTO_START brings the service back halfway through. One reporter who hit 0x80073D02 on every repair had this run clean on the first try.

If the deployment path itself is wedged, reboot and reinstall.

There's a variant where nothing of yours is holding anything: an orphaned per-package container still has a registry hive open, which surfaces as 0x80070020 (ERROR_SHARING_VIOLATION, 32) and the staged build never deploys. A reboot releases it. If the app is available from the vendor's download page, install it fresh after that reboot instead of fighting the in-app updater.

Last resort: remove and reinstall.

Get-AppxPackage -Name "*Claude*" | Remove-AppxPackage

Remove-AppxPackage only removes the package for the account(s) you target. A package provisioned for all users needs Remove-AppxProvisionedPackage with elevation, which is a different cmdlet.

The other codes in this family

Code	Message you'll see	What it usually means
0x80073D02	apps need to be closed / resources in use	Something from the old version is still running, often a packaged service
0x80073CF6	the package could not be registered	Stale or duplicate package state; also shows up when the package sits on a non-C: drive
0x80073CF9	package installation failed	Registration failed, and the inner error is the useful one
0x80073D05	error deleting previously existing application data	A half-written install left state behind
0x80073D28	administrator privileges required	A packaged service tried to register without elevation
0x80070020 (32)	the file is in use by another process	A file or registry hive is held open; a reboot releases it

You can't run binaries out of WindowsApps

This trips up anyone trying to work around a broken app by calling its bundled CLI directly. Files under C:\Program Files\WindowsApps are owned by the OS (TrustedInstaller) and locked down on purpose, so Access denied from your shell is the expected answer, not a permissions problem you can take ownership of.

If the app needs an external CLI, install it yourself and point the app at it:

npm.cmd install -g @openai/codex@latest
[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", "$env:APPDATA\npm\codex.cmd", "User")

One more drive-related trap, since it caught two reporters in a row: keep the package on C:. If Windows' "Where new content is saved" points at D:, some apps' internal path checks fail and the reinstall dies with 0x80073CF6.

Honest limits

I can be wrong about your specific install, and this doesn't cover every case. Two things I couldn't verify well enough to promise:

Sometimes Register succeeds and the app still won't launch. That's the OS servicing path stuck rather than a process pinning the package, and a reboot is the next honest step.
All of this is per-user. Clearing a packaged service for real may need elevation, and vendor dialogs will cheerfully say "administrator access is required" even when you already ran elevated. Trust the error code over the dialog.

So: when an MSIX app dies after updating itself, don't reinstall right away. Find what's still running under the package path and kill by path, not by name.

Sources: the reports I leaned on are in anthropics/claude-code issues 89599, 88962, 89108 and 88500, and openai/codex issues 38843 and 40867. Microsoft's AppX troubleshooting page covers the deployment error codes and the read-only package volume.

Windows won't boot but the disk is fine: rebuilding the EFI bootloader with diskpart and bcdboot

MilkyWay008 — Wed, 23 Sep 2026 17:17:17 +0000

Two dead laptops landed on my bench this month with the same story. Power on, vendor logo, then "Boot Device Not Found", or just a black screen. Both drives were healthy, and every file the owners cared about was sitting right there when I mounted the disks from a USB stick.

Windows didn't lose the data. It lost the small partition that tells the firmware where Windows lives.

It's a FAT32 partition called the EFI System Partition, and it has no drive letter. Nobody notices until a cloning tool skips it, an image restore drops it, or a resize eats it. Then the machine looks bricked while it's completely fine underneath.

Here's the fix I use. Fifteen minutes, and nothing you run here touches your files.

What actually boots a Windows PC

The firmware doesn't go hunting for Windows. It reads a boot entry out of NVRAM and loads a file called bootmgfw.efi from the EFI System Partition (ESP for short). Microsoft's partition docs put it plainly: the device must contain a system partition, and on GPT drives that's the ESP, formatted FAT32.

Two separate things can break: the files inside the ESP, and the firmware's memory of where the ESP is. Most of the "but bcdboot said it worked" cases I've run into are the second one.

Three checks before you type anything

Is the drive visible in firmware setup at all? If your SSD isn't in the BIOS or UEFI storage list, stop. That's hardware, a cable, or a storage-mode change like RAID versus AHCI. Not a bootloader problem, and nothing below will help.
Is the firmware in UEFI mode or legacy/CSM? A GPT disk won't boot through CSM on its own. Microsoft's Secure Boot guidance says it plainly: to use a CSM you may also need to reformat the drive as MBR and reinstall Windows. If a CMOS battery swap reset your board to legacy mode, you just found your answer.
Is BitLocker on? Find the recovery key before you touch boot files, because changing them can trigger a recovery prompt on the next boot.

Get to a command prompt in WinRE

Two routes:

From inside Windows: Settings > System > Recovery > Advanced startup > Restart now, then Troubleshoot > Advanced options > Command Prompt. Holding Shift while you click Restart from the power menu also works.
From a USB stick: boot Windows install media, choose Repair your computer, then Troubleshoot > Advanced options > Command Prompt.

The X: drive you land on is the recovery environment's RAM disk, not your Windows install. Your Windows volume is somewhere else, often with no letter assigned.

Find the two partitions you care about

diskpart
list disk
select disk 0
list volume
exit

You want two entries: a big NTFS volume (Windows) and a small FAT32 volume with no letter, usually 100 to 300 MB. That small one is your ESP.

Mount them with letters so the next commands have something to talk to:

diskpart
select volume 3
assign letter=S
select volume 4
assign letter=W
exit

Use the volume numbers you actually saw, not mine. Then check what you're looking at before writing:

dir S:\EFI\Microsoft\Boot
dir W:\Windows\System32

If dir W:\Windows answers with File Not Found, you picked the wrong volume. Go back to list volume. Guessing here is how people end up wiping the wrong partition.

Rebuild the boot files

bcdboot W:\Windows /s S: /f UEFI

Expect Boot files successfully created. That means bcdboot copied a fresh set of boot files from your Windows install onto the ESP and built a new BCD store there. It's the documented repair path: Microsoft describes bcdboot as the tool for repairing a corrupted system partition by recreating those files from the Windows partition.

Why it can still refuse to boot

This is the detail I wish someone had handed me years ago. Per the bcdboot docs: by default, bcdboot adds a firmware entry in NVRAM pointing at the Windows Boot Manager and puts it first in the boot list. But if you use the /s option, that NVRAM entry is not created. bcdboot then relies on the firmware's default behavior, which by the UEFI 2.3.1 spec should open \efi\boot\bootx64.efi from the ESP.

So bcdboot can print success while your firmware still points at a stale entry from an old disk or a cloning tool. Two things fix that.

First, give the firmware the fallback path it's looking for. Your ESP is already mounted:

mkdir S:\EFI\Boot
copy S:\EFI\Microsoft\Boot\bootmgfw.efi S:\EFI\Boot\bootx64.efi

Then reboot into firmware setup and move "Windows Boot Manager" to the top of the boot order. From WinRE, bcdedit /enum firmware shows the firmware entries, and running bcdboot again without /s lets it create the NVRAM entry itself. Be careful with that one if the machine has more than one ESP, since without /s you're trusting it to pick the right disk.

If Secure Boot is in the picture, test one boot with it disabled to see whether the bootloader is even the problem, then turn it back on. Don't leave it off.

When the BCD store itself is missing

bootrec /scanos
bootrec /rebuildbcd

/scanos looks for Windows installations, /rebuildbcd builds a store from whatever it finds. The older /fixboot often just answers "Access is denied" on UEFI machines. I can't point you to an official page for that one, it's what I keep seeing, and my read is there's no legacy boot sector left for it to rewrite. Once bcdboot has written the ESP files you usually don't need bootrec.

What can't hurt your data, and what can

Safe, because none of these writes to your files: diskpart list, select, assign, bcdboot, bootrec, bcdedit. Assigning a letter just puts a name on a volume that already exists.

Never a first move: diskpart clean, format, convert gpt, deleting volumes. If the drive is clicking, or the files matter more than the machine boots, clone it and repair the clone.

The short version

USB stick, command prompt, diskpart to find the FAT32 ESP and the Windows volume, bcdboot W:\Windows /s S: /f UEFI, copy bootmgfw.efi to \EFI\Boot\bootx64.efi, set the boot order. That's the whole job.

I've only done this on straight UEFI and GPT single-disk machines, so your mileage will vary on RAID, Storage Spaces, or a legacy/MBR setup. And if the firmware can't see the drive at all, the hardware comes first. But for the "bricked" laptop with a perfectly good disk...... this one has saved me a reinstall more than once.

uv lock says "No solution found": how to read the dependency deadlock and break it

MilkyWay008 — Tue, 22 Sep 2026 17:07:21 +0000

You add one library, run uv lock, and the resolver prints 40 lines of "Because ... And because ..." and quits with a non-zero exit code. You did not change any pins. The project was fine yesterday.

I have run into this class of failure a few times and it usually ends the same way: the resolver is right, and one package in the graph has a stale upper bound.

What that wall of text is saying

The first line is the one that matters:

× No solution found when resolving dependencies:

Everything after it is a derivation chain. Each line is a requirement read out of some package's metadata, and the chain ends where two of them want different things.

A real example, from a LangGraph issue (langchain-ai/langgraph#8352): langgraph-api 0.11.0 pins opentelemetry-exporter-prometheus<0.59, which forces opentelemetry-sdk into an old range. Meanwhile pydantic-ai 2.x pulls logfire>=4.35.0, which wants opentelemetry-sdk>=1.39.0,<1.43.0. Those two ranges never overlap, so no set of versions satisfies both.

Nobody is being unreasonable here. That 0.59 bound was probably correct when someone wrote it...... it just never got revisited. The person who filed the issue could not fix it either, because the metadata ships from a private source tree, so only the maintainers can widen the pin.

Two commands make the chain readable:

uv lock -v                            # full derivation, as the resolver sees it
uv tree --invert opentelemetry-sdk    # who wants which version

Read the chain bottom-up, find the two packages that disagree, ignore the middle.

The silent downgrade is worse than the error

In that same issue the resolver could quietly settle on a much older langgraph-api (0.7.27 was observed), and langgraph dev fell back to an older build without complaining. The app boots, on code you did not ask for, and the Studio upgrade banner stays unsatisfiable.

That one costs people days, because nothing looks broken. A successful resolution is not proof you got what you wanted. Check the installed version, not the requested one.

Constraints cannot fix a deadlock (this is the part people get wrong)

uv has two settings for this, both in the workspace-root pyproject.toml under [tool.uv]. They look similar and behave nothing alike.

constraint-dependencies is additive. The docs describe constraints as restricting "the versions of dependencies that are selected during resolution", so they get intersected with whatever the packages already declared.

override-dependencies is absolute. The docs say overrides "force selection of a specific version of a package, regardless of the version requested by any other package, and regardless of whether choosing that version would typically constitute an invalid resolution". The resolution docs call overrides the escape hatch for erroneous upper version bounds.

So when the ranges are disjoint, a constraint can never save you. Constraints only narrow the space, and the space is already empty. This matters because the reflex is to reach for a constraint when the real tool is an override.

[tool.uv]
# stops the resolver from silently picking something ancient
constraint-dependencies = ["langgraph-api>=0.10.3"]

# the deadlock breaker: deliberately contradicts a declared upper bound
override-dependencies = ["opentelemetry-exporter-prometheus>=0.63b1"]

One placement gotcha: uv reads these from the workspace root only. Putting them in uv.toml, or in a member package's pyproject, does nothing.

The order I would try things

1st, pin the thing that moved back to the last version that worked. Boring, safe, usually enough to get moving today.

2nd, add a floor constraint on whatever was being silently downgraded, so you find out about it instead of living with it.

3rd, override the stale bound, then actually run the app. uv lock exiting 0 only proves the graph resolves. The package that asked for the old SDK is now untested territory.

4th, if the two libraries genuinely cannot coexist, give them separate environments. Ugly, but honest, and sometimes correct.

Leave a trail

Keep the override in the file with a comment, a link to the upstream issue, and the date you added it. An override without a note turns into permanent mystery debt six months later. In this case the pin was widened on the 0.13.0 dev line (<0.64,>=0.63b1, landing the SDK at 1.42.1) while stable still carried the old bound, so the plan is: wait for the release, then delete the block.

If you use pip instead of uv, the constraint file (pip install --dry-run -c constraints.txt) is additive in the same way, so it will not break a disjoint range either. Worth knowing before spending an hour on it.

I can be wrong about your particular graph, but from what I have seen the fix is rarely a clever resolver flag. It is reading the chain, working out which bound is stale, and forcing that one thing while you wait for upstream...... then writing down why.

One honest gap: I could not independently confirm whether stable langgraph-api still carries <0.59 at the time of writing. The issue is open. Check it before copying the override.

HTTP 400 from your own LLM endpoint? Check for content: null

MilkyWay008 — Mon, 21 Sep 2026 17:28:55 +0000

Someone I was helping had a tidy little setup: a self-hosted OpenAI-compatible endpoint in front of their model, a coding agent pointed at it, months of smooth sailing. Then they bumped the agent from 7.3.42 to 7.3.44 and every request came back HTTP 400. Same endpoint, same key, same model. Only the client version changed.

The error body was short, and it looked roughly like this:

400 Bad Request
{"error": {"message": "Type validation failed",
           "path": "/messages/2/content",
           "keyword": "invalid_union"}}

If you run a gateway in front of a local model (vLLM, LiteLLM, llama.cpp, Open WebUI, LM Studio, or your own FastAPI shim), this one will find you eventually. The error already tells you where to look, and the fix is usually a couple of lines on whichever side of the wire you control.

The field it names is the whole clue

/messages/2/content means the third message in the array, its content field, and a union check that failed. Validators generated from a schema (pydantic, zod, ajv and friends) hand you the JSON path for free. Read the path first, then read the raw request, and stop guessing about the model.

Log the outgoing body at the gateway (raw JSON, not a redacted summary), find that index, and look at the message. In this case it was an assistant message with tool calls and no text:

{
  "role": "assistant",
  "content": null,
  "tool_calls": [
    {"id": "call_1", "type": "function",
     "function": {"name": "read_file", "arguments": "{\"path\": \"a.txt\"}"}}
  ]
}

Nothing looks broken there. That's the trap.

What changed, and why neither side is crazy

On the client side, Vercel's AI SDK changed tool-only assistant messages from content: "" to content: null on purpose. The commit message spells out why (vercel/ai@bfb756d8, April 2026): providers backed by AWS Bedrock reject an empty text block with ValidationException: text content blocks must be non-empty, so the serializer became content: text || null. A lot of coding agents sit on top of that SDK, which is why the change showed up in several places at once.

On the server side, the endpoint's validator insists that an assistant content is a string. Null isn't a string. Union check fails, request dies.

OpenAI's own schema allows null, though. In the OpenAI OpenAPI spec, the assistant message defines content as string | array of parts | null, described as "The contents of the assistant message. Required unless tool_calls or function_call is specified." The only required property on that object is role.

So content: null on a tool-call-only assistant message is legal, and the validator is the piece that's out of step with the protocol. "My schema says no" is a different sentence from "the spec says no."

Fixing it

If you own the endpoint, normalize at the edge. Accept null when tool calls are present, and rewrite it into something your backend tolerates. A small piece of Starlette middleware is enough:

import json
from starlette.middleware.base import BaseHTTPMiddleware

def normalize(body):
    for m in body.get("messages", []):
        if m.get("role") == "assistant" and m.get("tool_calls") and m.get("content") is None:
            m["content"] = ""   # or " " if your backend also dislikes empty strings
    return body

class NullContentFix(BaseHTTPMiddleware):
    async def dispatch(self, request, call_next):
        if request.url.path.endswith("/chat/completions"):
            payload = await request.json()
            request._body = json.dumps(normalize(payload)).encode()
        return await call_next(request)

That comment about empty strings isn't hypothetical. Continue's OpenAI converter does message.content || " " with the literal comment "LM Studio (and other providers) don't accept empty content." Different clients picked different workarounds for the same edge case, which is a decent hint about how long this has been rattling around. If your backend is picky about empty strings too, coerce to a single space.

If you don't own the endpoint, pin the client. The actual difference between working and broken was @ai-sdk/openai-compatible 2.0.41 versus 2.0.48. A sibling tool still sitting on 2.0.41 was reported working against the same endpoint, which is a reminder that "it works in tool X" says nothing about your config. Pin it in the lockfile, or put your own proxy in the middle to rewrite null.

And don't wait on the upstream fix. A normalizing pull request for the client was opened and closed without merging (kilocode#12331; the original report is kilocode#12330), so as of today it's on you to pin or normalize.

The same 400 in other disguises

Once you've seen one message-shape mismatch, you spot them everywhere. The ones I keep running into:

Reasoning blocks that don't survive a round trip. Open WebUI dropped the Anthropic thinking-block signature when saving reasoning_details, then replayed the unsigned block on the next turn. Anthropic rejects it with Invalid signature in thinking block, so turn 2 dies every time, identically across five providers (open-webui#27467). The fix PR is closed without merging, so stripping unsigned reasoning from prior assistant turns in a proxy is the workaround for now.
Streaming reasoning where delta.content isn't a string. n8n 2.36.8 with the Mistral Chat Model: content arrives as an array of thinking blocks, the node's schema wants a string, and you get invalid_union. Routing through a proxy that strips thinking deltas worked (n8n#37352, which n8n closed on Sep 8).
Extra parameters the client started injecting. One client began sending prompt_cache_breakpoint to a custom Responses endpoint and got 400 invalid_parameter on every request, reproducing on a clean VM (kilocode#13285). Strip the unknown field at the proxy, or pin the client back.
Role remapping that breaks the model's chat template. LM Studio maps each developer message to its own system message, so the second one lands mid-prompt and Qwen's Jinja template throws System message must be at the beginning (lmstudio#2298). Consolidate developer messages client-side, or fall back to /v1/chat/completions.

The habit that saves the evening

When a proxy or router sits in the middle, the 400 is often produced by the translation layer, not the model. Test with tools disabled, try the same model through a different route, and read the JSON path in the error before touching anything else.

Then decide who owns the field, fix the side you control, and pin the version of the thing that changed instead of the whole stack.

And if you happen to be the one writing the validator: accept null on assistant messages that carry tool calls. It's in the spec.

I've only hit this on a handful of stacks, so treat it as a starting point rather than gospel, and test it against your own gateway. I keep notes on this class of failure in a small KB repo, Windows-flavoured more often than not: hermes-kb-hack-fix. Hope it saves you an evening.