Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last) (part 2)

What it is

This is part 2 of the Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last) page. It carries the next stretch of the material on that page, moved here because a single page is capped at 40,000 characters.

Where to find it

Reach this part through Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last) — it lists every part and explains where the feature lives in the product. Everything below is reached from the same place.

How it behaves

Everything below is the behaviour, detail and edge cases that belong to this stretch of the Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last) page.

Tier 2 — Free, but needs a restart or a quick cleanup

Running fewer sessions is never the fix. Session and process count is not what makes a machine crawl — a hundred running clean is the normal baseline, not the ceiling. If Omniscio freezes your computer under load, that is a bug in Omniscio, and shedding sessions only hides it: the freeze stops being reproducible and never gets fixed. Report it (bottom of this page) instead. The dials below pace the starts; they don't ask you to do less.

1. Widen the start spacing (do this first if a burst is what hurts). A machine usually tips over when many things start in the same instant, not from the amount of work. Settings → Performance gives you two spacing dials — "Spacing between sessions when many restart at once" and "Wait between automation-created new sessions" — so a big wave trickles in instead of landing all at once. Same work, no spike. Full explanation under If RAM is fine but it freezes in bursts: a spawn storm below.
2. Relaunch Omniscio to pick up shipped speed-ups. If you have been running the same build for a while, relaunching adopts every performance fix that has shipped since, and frees memory a long-running app or a just-disabled feature was still holding. Treat this as a build refresh, not a cure: if a relaunch reliably makes a freeze go away, that is the bug reproducing — please report it before it fades.
3. Turn off background features you don't use, then restart. Anything that scans files or polls on a timer adds constant load. If you don't use a feature, turn it off — and restart Omniscio afterward, because some features keep working until the next launch.
4. Sweep abandoned project copies (developers / heavy multi-session users). If you use Omniscio to run many coding sessions, leftover git worktrees — each with its own node_modules — can quietly pile up to hundreds of gigabytes and get re-scanned forever by backup and antivirus software. Cleaning them up is one of the biggest wins for a developer machine. Omniscio already sweeps these in the background on a schedule; heavy users can tune how often (and whether it uses AI to judge which stalled copies are safe to remove) from the Dev Pipeline panel's Setup tab. On Windows, Omniscio also keeps these worktree folders out of the Windows Search index automatically — no administrator prompt — so the indexer never crawls every copy (a project kept in Documents used to make it crawl millions of files). Want one indexed anyway? Re-tick it in Windows' Indexing Options; Omniscio won't undo that.
5. Reclaim space from Omniscio's own database (if it has grown huge). Everything Omniscio remembers — your projects, sessions, and every message — lives in a single database file that only ever grows: deleting old chats leaves reusable empty space inside the file rather than handing it back to your disk, so after heavy use it can sit at several gigabytes that are mostly empty. Settings → Diagnostics → "Reclaim disk space" clears cached chat layouts and schedules a one-time compaction that runs at your next restart (behind the splash) and physically shrinks the file — your conversations are untouched. This is Omniscio's own database; it's separate from the git repo cleanup some developers need further down. See database-compaction.md.

Advanced — Windows power-user cleanup (optional)

These genuinely help, but they touch system settings and need an administrator "Yes" (UAC). If you're not comfortable, the easiest path is to ask your Omniscio agent to do it for you ("Please add a Defender exclusion for my Omniscio repo and explain what you changed") — the agent can read your current values and apply the change precisely. Or skip them — Tiers 1–2 above already do most of the work.

You may not have to come looking for this. If Omniscio freezes for a few seconds more than once after it has finished starting up, it raises an inbox card — "The app froze more than once" — and that card now names antivirus scanning as the usual cause and an exclusion as the fix. Its Start session button opens a session that checks your machine and walks you through it. The session looks first and asks before changing any security setting, so nothing is switched off behind your back. Fresh machines are the classic case: the scanner has never seen Omniscio's files, so it scans each one the first time Omniscio touches it, and a microsecond file write becomes a multi-second one. Freezes while Omniscio is still starting up (the loading screen is showing) never raise this card and never count toward it — a slow start is not the app freezing while you use it.

• Antivirus (Defender) exclusion for a big dev repo + its worktrees, and Omniscio's data folder. Antivirus real-time-scanning the constant file churn can burn ~1 GB of RAM and real CPU.

  Contributing to Omniscio's own codebase? The Defender half is done for you. Running npm run setup in the Omniscio repo excludes from Defender: the repo, every worktree container the app can create in, Omniscio's live data folder, the shared node_modules base on each drive that has one, the pnpm store, and the app's own churn folders — one administrator prompt the first time, none afterwards, and the repo's SETUP.md lists how to undo it. Folders that do not exist on your machine are left out rather than asked for, so you do not get a permanent "still missing" note about a drive you never had. It skips the prompt entirely if you are not on Windows, have no terminal, or say no, and it never blocks the setup either way. Windows Search needs nothing from setup: the app keeps its own worktree folders out of the index for everyone (see step 4 above); to keep the repo itself out as well, untick it once by hand (Settings → Privacy & security → Searching Windows → Advanced Indexing Options → Modify). That's a contributor-only convenience; the manual steps below are what everyone else wants, and they apply to any project.

  In an elevated PowerShell:

  # Use YOUR repo path; repeat for the Omniscio data folder if you wish
  Add-MpPreference -ExclusionPath "C:\path\to\your\repo"
  Add-MpPreference -ExclusionPath "$env:APPDATA\omniscio"
  
  # Also exclude the busy programs by NAME — stops the scanner inspecting every
  # file they open while running, including Omniscio writing to its own database:
  Add-MpPreference -ExclusionProcess "node.exe"
  Add-MpPreference -ExclusionProcess "git.exe"
  Add-MpPreference -ExclusionProcess "electron.exe"
  

  Excluding the folders stops the files on disk from being scanned; excluding the processes stops the scanner from checking what those programs open while they run — which matters because Omniscio's own app (electron.exe) constantly writes to its database, and every one of those writes was being scanned. (Also worth excluding the same folders from any cloud backup app — e.g. Backblaze — and from any file-search indexer that watches your drives (Windows Search, or third-party tools like Everything) — any of these can otherwise re-scan millions of tiny dependency files as they churn and sit at the top of your CPU or RAM usage.)

• Even better than the exclusion above: put your heavy file activity on a Windows 11 "Dev Drive." A Dev Drive is a kind of drive built into Windows 11 for exactly this. On it, Microsoft Defender runs in performance mode — it scans files after they're written instead of pausing every file operation to check it first, so you keep antivirus protection but lose the constant real-time-scan tax. That's a big win because Omniscio and the coding sessions it runs touch a huge number of small files. It's our own setup: Omniscio's repo, its package cache, and all its working copies live on a Dev Drive, so installs are fast and the file churn isn't scanned in your way. Put your code projects, package caches, and git worktrees on it (for Omniscio's data folder itself, the next bullet is the dedicated, reversible way to move it). Don't put Windows, your installed apps, or the Omniscio program itself on it — a Dev Drive is for the busy data, not the system. Two guardrails we learned the hard way:

  • Size it generously and keep free space. A nearly-full Dev Drive flips from a speed-up into a new cause of freezes (it stalls on its own bookkeeping and every file operation waits on it) — make it large, and sweep abandoned worktrees (Tier 2.4 above) so it never fills.
  • Put it on a fast SSD. It only helps if the disk underneath is fast; moving your work onto a drive slower than your system drive can be a net loss.
  • To create one (Windows 11 only): Settings → System → Storage → Advanced storage settings → Disks & volumes → Create Dev Drive (at least 50 GB — ideally much more). If the menu doesn't match your build, ask your Omniscio agent: "Please set up a Windows Dev Drive for my code and explain what you changed." (Performance mode is a Microsoft Defender feature; a third-party antivirus may still scan these files.)
  • Watch for the Windows file cache ballooning (a ReFS Dev-Drive quirk worth knowing). Heavy file churn from many sessions can make Windows' own file cache swell to tens of gigabytes and push your available RAM toward zero — which then triggers the exact swap-thrash freezes at the top of this guide. The tell is unusual: your available memory is low but your actual programs aren't using much — it's nearly all "cached." Omniscio watches for this and raises an inbox alert ("Windows file cache is crowding out memory") when it happens. A restart clears it immediately; if it keeps recurring, ask your Omniscio agent: "My available RAM keeps disappearing into the Windows file cache — please cap the Windows system file cache so it can't balloon." (The agent installs a size cap so the cache can never crowd out your apps.)

• Move Omniscio's data folder to a drive nothing else is hammering. This fixes one very specific — and very annoying — pattern: only Omniscio gets slow (scrolling stutters, typing lags, switching chats takes seconds) while the rest of your computer feels fine, and it is worst exactly when your machine is doing heavy file work — builds, big downloads, or many coding sessions churning files. What's happening: Omniscio keeps everything it knows in a database on one disk, and when other software hammers that same physical disk, every read Omniscio needs waits in line behind it. Two things make this sneaky: drive letters can lie (two letters — say C: and K: — are often partitions of one physical disk, so "my projects are on a different drive" may not actually be true), and under sustained disk traffic Windows also evicts Omniscio's in-memory database cache, forcing the app to re-read from the busy disk at the worst possible moment. The fix is to give Omniscio's data a quiet home of its own. The safe way is to ask your Omniscio agent — paste this into any session: "Omniscio gets slow while the rest of my computer is fine, especially during heavy file work — please check whether Omniscio's data folder shares a physical disk with the busy work, and if so move it to a quieter internal SSD. Copy, don't move, so the original stays as a fallback, and walk me through the restart." For reference, what the agent (or a comfortable power user) actually does: quit Omniscio; copy — don't move — the whole data folder %APPDATA%\omniscio to a folder on the quiet drive (say H:\AMC-Data\agent-mission-control); set the user environment variable DATA_DIR to that new path; start Omniscio again from a new terminal or shortcut (windows opened before the change still carry the old setting). Two guardrails: pick an internal SSD that nothing busy touches — not the drive your projects, worktrees, or downloads churn on, and not a USB drive — and always copy, so the original folder stays intact as an instant fallback. Undo any time: quit Omniscio, delete the DATA_DIR variable, start it again (again from a new window) — you're back on the original folder exactly as it was. One scare to know about in advance: if Omniscio ever opens looking brand-new (empty, no sessions), the variable is pointing at a wrong or empty folder — nothing is lost; quit, fix or delete the variable, and relaunch.

• Still Defender after all that? It's Behavior Monitoring, not file scanning — the one part exclusions can't fix. If you've done the exclusions above (and maybe moved work to a Dev Drive) and Defender — shown as "Antimalware Service Executable" (MsMpEng) in Task Manager — is still near the top of your CPU, the cause isn't files being scanned anymore. It's Behavior Monitoring: the part of Defender that watches how your running programs behave, which folder and process exclusions do not turn off. On a machine running a swarm of Omniscio sessions it watches every one, so it keeps costing CPU no matter how much you exclude. Two things make it stubborn: it can only be changed while Tamper Protection is turned off (with Tamper Protection on, the setting silently flips back), and turning it down is a real security trade-off. The safe way is to let your Omniscio agent do it — say "Defender is still my top CPU user even after exclusions — please turn off Behavior Monitoring but keep real-time file protection on." The agent turns Tamper Protection off, disables only the behavior engine (your real-time file/malware scanning stays on), and can lock the setting so a Windows update doesn't quietly switch it back. It's fully reversible. (You keep protection against known malware in your files; you give up Defender's guesses about suspicious behavior — usually a fair trade on a busy dev machine, and your agent will explain it before making the change.)

  Contributing to Omniscio? There is a command for this. npm run harden:windows does the whole thing in one administrator prompt: turns Defender's real-time scanning off at the policy level, and stops Windows Update restarting your machine on its own. Undo it with npm run harden:windows -- --revert. It is opt-in and never part of npm run setup — this is a much wider trade-off than a folder exclusion, so nobody's machine gets it without asking.

  It exists because the obvious ways do not stick. Turning Defender off in the Windows Security app, or with Set-MpPreference, is designed to be temporary — Windows silently switches it back on after a while and again at every reboot, which is why re-clicking the toggle never works. Only the Group Policy form persists, and only while Tamper Protection is off. A Windows feature update can still reset it, so the command also installs a small task that re-applies the setting at every boot.

• Cap the Windows pagefile so it can't fill your system drive. Only if the scan showed a growable ("system-managed") pagefile and your system drive is filling up. Pick a fixed size at least as large as your RAM (too small risks out-of-memory crashes). In an elevated PowerShell (example pins it to 32 GB — adjust to your machine):

  $pf = Get-CimInstance Win32_PageFileSetting -Filter "name='c:\pagefile.sys'"
  $pf | Set-CimInstance -Property @{ InitialSize = 32768; MaximumSize = 32768 }  # MB
  

• Raise the Windows desktop-heap limit (the most advanced — best left to your agent). On a machine launching hundreds of processes, Windows can hit a built-in ceiling and refuse to start new ones, which looks like a stall. The fix raises one registry value and needs a reboot. The safest way is to ask your Omniscio agent: "Please raise my Windows desktop heap to 64 MB and tell me exactly what you changed." For reference, the value lives at HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems → the Windows entry → the SharedSection=1024,20480,768 part, where the middle number (desktop heap in KB) is raised (e.g. 20480 → 65536). Mistyping this can stop Windows from booting — let the agent do it, or skip it.

---

If RAM is fine but it still freezes: a stuck Windows service

If the Step 0 checks show plenty of free RAM yet the machine still freezes — and the CPU sits pinned near 100% doing "kernel/system" work rather than your own apps — the usual cause is a Windows background service stuck in a loop. A couple of Microsoft's own optional services are the known offenders: whesvc ("Windows Health and Optimized Experiences") and webthreatdefsvc ("Web Threat Defense"). When one wedges, it spins furiously — hundreds of thousands to millions of tiny CPU hand-offs a second — while using almost none of its own CPU. Running at normal priority, it crowds your window off the processor and the whole machine hitches, no matter how much RAM you have.

How to spot it: the Step 0 "stuck service" check shows one svchost generating far more CPU hand-offs than anything else, the thread queue is very high, and disk and RAM are both fine.

The fix — let your Omniscio agent do it. Open any session and say: "My computer keeps freezing but RAM is fine — please find the stuck Windows service and fix it." The agent can pinpoint exactly which service is spinning and restart it (that clears the wedge instantly, no reboot). If it turns out to be a non-essential service like whesvc — optional health telemetry that nothing else depends on — the agent can disable it so it can't come back. A protected Defender service like webthreatdefsvc (which powers Windows' Enhanced Phishing Protection) can't be disabled the usual way, and just restarting it clears the spin only until it wedges again. There's still a durable fix: turn that feature off by policy — the service then goes idle and stops on its own, usually within a minute, no reboot needed. The trade-off is losing Windows' phishing-site and password-reuse warnings, so it's a small security choice your agent will flag before making it. Don't disable a service by hand on a guess — let the agent confirm which one it is first, so you never switch off something Windows actually needs.

One reason a stuck service can hide for a long time: it may spin in bursts — hundreds of thousands of tiny CPU hand-offs one second, almost none the next — so a single quick sample can look calm and miss it. The reliable tell is the Step 0 check seen across several looks: one svchost generating far more CPU hand-offs than everything else. For reference, the durable off-switch an agent applies for webthreatdefsvc — turning off Windows' Enhanced Phishing Protection so the wedged service goes idle — is, in an elevated PowerShell:

$k = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WTDS\Components'
New-Item -Path $k -Force | Out-Null
# Turn off Enhanced Phishing Protection (what webthreatdefsvc powers); it then goes idle:
'ServiceEnabled','NotifyMalicious','NotifyPasswordReuse','NotifyUnsafeApp','CaptureThreatWindow' |
  ForEach-Object { Set-ItemProperty -Path $k -Name $_ -Value 0 -Type DWord }

---

If RAM is fine but one DRIVE is pinned: a Windows file-crawler

A third variation, and the one most likely to bite you if you keep a lot of project folders on one drive. RAM is fine, the CPU is fine, and most of your drives are idle — but one of them is completely jammed, and everything hitches whenever an app touches that drive.

The usual culprit is InventorySvc ("Inventory and Compatibility Appraisal service"), a Windows telemetry component that periodically walks your disks cataloguing installed software. On an ordinary PC you'd never notice. But every developer project folder carries its own node_modules (or equivalent) holding tens of thousands of small files, so if you keep dozens or hundreds of them, that crawl becomes millions of files — and it will grind that drive continuously.

How to spot it: the tell is a split — one drive at ~0% idle with a long queue of waiting requests, while your other drives sit near 100% idle. That asymmetry is the whole diagnosis: a genuinely overloaded machine slows everything down; a crawler pins exactly one drive.

Measured on a real developer machine (2026-09-02). With 263 project folders on one drive, InventorySvc was the single biggest disk user on the box at ~40,000–75,000 file operations per second — an order of magnitude above any real application. That drive sat at a queue depth of 96 with 0% idle while every other drive was 65–100% idle. Turning the service off moved that same drive to a queue of 0.6 and 56% idle, and the app's worst-case delay dropped by about 40%.

The fix — let your Omniscio agent do it. Open any session and say: "One of my drives is pinned but RAM and CPU are fine — please check whether a Windows crawler is hammering it." The agent confirms which process it actually is by process ID before touching anything, then stops and disables it. Nothing you use depends on this service: it does not serve Windows Update, security, or any app-compatibility behavior you'd notice. For reference, in an elevated PowerShell:

# Confirm it is really the culprit FIRST — never disable a service on a guess:
Get-CimInstance Win32_Service -Filter "Name='InventorySvc'" | Select-Object Name, State, ProcessId
# Then stop it and keep it from coming back:
Stop-Service -Name InventorySvc -Force
Set-Service  -Name InventorySvc -StartupType Disabled

To undo it at any time: Set-Service -Name InventorySvc -StartupType Automatic then Start-Service -Name InventorySvc.

Can it turn itself back on? Essentially no — but check after a big Windows version upgrade. Once it is set to Disabled, Windows writes that to the registry and honors it across reboots; the service also registers no start triggers, so nothing else can wake it on demand, and its automatic-restart-on-crash setting can't apply to a service that is never allowed to start. The one realistic exception is a Windows feature update (a version upgrade, not the monthly patches), which reinstalls system components and can reset service settings to their defaults — as can a repair such as sfc /scannow or a DISM restore. So it will not come back on its own, but it is worth re-checking after a version upgrade. The Step 0 scan above includes that check, so any future "my computer feels slow" pass catches it automatically.

Related, and worth doing anyway: fewer project folders means less for any crawler (and your own tools) to walk — see Tier 2 on sweeping finished worktrees.

---

If RAM is fine but it freezes in bursts: a spawn storm

A close cousin of the stuck-service case above, with a different signature. Here the machine freezes for a few seconds to a minute and recovers on its own, RAM is fine, and no single process is the hog — and it tends to hit right when a lot of work starts at once: a batch of builds/tests, a CI run, or many sessions kicking off jobs at the same moment. Afterwards nothing looks wrong, which is what makes it maddening.

This is a spawn storm (a "runnable-thread stampede"): dozens of short-lived helper processes get created in the same instant, and creating that many at once floods the Windows scheduler so hard that even your window can't get a turn — so the whole machine stalls until the burst drains. The tell is different from a stuck service: instead of one svchost pinned, it's a sharp jump in the number of running processes right at the freeze, and the little processes vanish within a second or two — so by the time you look, the evidence is gone.

Why it hides: ordinary tools sample every few seconds and miss anything born-and-died between samples; during the freeze the sampler is starved too. The reliable way to catch it is to record every process the moment it is created and read it back after the freeze.

The fix — let your Omniscio agent do it. Open any session and say: "My computer keeps freezing in short bursts but RAM is fine — please turn on process-creation auditing, wait for the next freeze, and tell me what is spawning the burst." The agent switches on Windows' process-creation log (Event 4688, which stamps every process at birth with its parent and full command line), waits for the freeze, then groups the burst by parent — the one parent that spawned dozens of children is what fanned out, and its children's command lines name the exact job. For reference, the developer commands (an elevated PowerShell) are:

# Arm: record every process creation, with its command line
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f
auditpol /set /subcategory:"Process Creation" /success:enable
# ...after the next freeze, read that burst grouped by parent (last ~3 minutes shown):
$ev = Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4688; StartTime=(Get-Date).AddMinutes(-3) }
$ev | ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq 'ParentProcessName' } |
  Group-Object '#text' | Sort-Object Count -Descending | Select-Object Count, Name -First 10
# Disarm afterwards (it is verbose): auditpol /set /subcategory:"Process Creation" /success:disable

The real fix is usually to pace the starts, not to run less. When a burst is real, the cure is spacing those job starts a fraction of a second apart instead of letting them all launch in the same instant — the same amount of work, no spike. Omniscio already does this for its own heavy background jobs (builds/tests/lint) through its job pacer, so a swarm of sessions can't stampede your machine. On developer machines Omniscio also paces what the agents themselves launch: their searches and their npm/npx/pnpm job starts are spaced out automatically, the spacing widens as the machine heats up, and at storm-level CPU new launches briefly hold so the machine drains instead of tipping over. Agent recursive grep and find also automatically skip the heavy folders (node_modules, the worktree piles, build output), so one careless search can't walk millions of dependency files and spike the disk — and that protection is built in and self-repairing, so it can't be silently lost. Dependency installs go one step further: an agent's npm install / pnpm install now takes a turn through a shared "install slot," so only one install writes to the shared package store at a time instead of a dozen agents all unpacking packages onto the disk at once — one of the heaviest disk bursts a swarm of sessions can create (it's the same one-at-a-time rule Omniscio already uses for its own project-setup work). A busy machine may make an install wait for its turn. If exclusive admission cannot be proven before the safety deadline, that install is refused and can be retried later; it never proceeds beside another store writer. This protects dependency integrity and slows agent work rather than the Omniscio window. And when the box is genuinely overloaded, an agent's heavy one-off commands — a typecheck, a test run, a build, an unusual search tool, or a tool launched by its full path — are briefly held until the machine cools (bounded, then always allowed), so a big job can't launch straight into a freeze; this catches the odd shapes the automatic pacing above can't see. And for the session starts themselves — the wave when many come back after an app restart or a rate-limit recovery, or when you restart a whole batch at once — Settings → Performance gives you two spacing dials: "Spacing between sessions when many restart at once" and "Wait between automation-created new sessions." Each defaults to Omniscio's current timing; widen it so a big wave of starts trickles in instead of landing all at once (set either to 0 to turn its spacing off). Sessions you start or restart by hand, one at a time, are never delayed. If you are a developer whose own tooling causes the storm, cap the rate things start, not just how many run at once.

---

Alt+Tab protection is automatic on Windows. When every Omniscio window loses focus, the app immediately moves its running agent process trees to Windows' strongest background-yielding CPU priority. The application you switched to gets first claim on the processor while all sessions keep running; focusing any Omniscio window restores their normal priority immediately. There is no setting to manage and no session-count limit involved.

---

Related

The overview, the other parts, and everything else worth reading next all sit on Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last).