DEV Community: Karim Masmoudi

Shipping a Swift CLI on Windows: what broke

Karim Masmoudi — Sun, 11 Oct 2026 17:01:29 +0000

Mudroom runs coding agents like Claude Code, Codex or Gemini CLI in a Linux container, on a copy of your project, and lets you review their changes like a pull request before anything touches your real files. It started as a Mac app. Version 0.2.0 adds a Windows build of the CLI, for x64 and arm64, using Docker Desktop or Podman as the sandbox.

Swift on Windows works better than I expected. Most of the code compiled once the platform-specific parts were split out. What took the time was everything around the compiler: linking, sockets, the file system, PowerShell and CI. Here's what broke, in case you're about to do the same.

1. The C++ headers refuse the compiler

The first build failed before compiling a single Swift file. Swift 6.2 ships Clang 19, and the Visual Studio 2026 C++ headers on GitHub's Windows runners refuse anything older than Clang 20. The headers have an escape hatch:

swift build -Xcxx -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH

It's in every Windows build command in CI now, and in the README for anyone building from source.

2. There's no static standard library

On Linux you can pass --static-swift-stdlib and get one binary. On Windows that flag builds, but the exe still imports swiftCore.dll and friends. -Xswiftc -static-stdlib fails outright with "unable to load standard library", because the Windows SDK ships no static Swift libraries.

So the release zip carries the DLLs. The packaging script doesn't use a hand-written list. It runs dumpbin /dependents on the exe, then on every DLL it finds, until nothing new shows up. That gives 15 DLLs on both architectures:

the Swift runtime: swiftCore, swiftCRT, swiftWinSDK, swift_Concurrency, swift_StringProcessing, swift_RegexParser, swiftDispatch, dispatch, BlocksRuntime
Foundation: Foundation, FoundationEssentials, FoundationInternationalization and _FoundationICU (the ICU data alone is about 36 MB unpacked)
the Visual C++ runtime: VCRUNTIME140 and MSVCP140

The zip ends up around 29 MB. To check that it really runs without Swift installed, CI unzips it on a separate runner that never had a Swift toolchain. It confirms there's no swift on PATH, runs the full smoke test, then renames swiftCore.dll and checks that the exe now fails to start with 0xC0000135 (DLL not found). Without that last step, a stray Swift install on the runner could make the test pass for the wrong reason.

3. A socket is not a file descriptor

On macOS and Linux a socket is a file descriptor, and close() closes it. On Windows a socket is a SOCKET handle from Winsock, and handing it to the C runtime's close() crashes the process. Two tests did exactly that. The fix is a small Sock.close that calls closesocket on Windows, and using it everywhere.

4. The 503 that never arrived

Mudroom's network proxy caps how many connections it serves. Over the cap, it writes a 503 and closes the connection. On Windows the client never saw the 503.

If you close a TCP socket while the peer's request is still unread in your receive buffer, Windows sends a reset instead of a normal close, and the reset throws away the 503 the client hasn't read yet. On Windows the proxy now shuts down its sending side, then reads and discards the request for up to 250 ms, so the client gets the 503 before the connection goes away.

5. Atomic writes meet antivirus

Session state is written to a temp file, then moved over the old one with MoveFileExW(..., MOVEFILE_REPLACE_EXISTING). That failed now and then with a sharing violation. Something else had the file open for a moment: Defender scanning the new file, or the search indexer.

The fix is boring. On ERROR_SHARING_VIOLATION or ERROR_LOCK_VIOLATION, wait 50 ms and try again, up to ten times. macOS and Linux keep Foundation's plain .atomic write.

6. Files don't work the way Unix code expects

A diff tool cares about file metadata, and Windows has different metadata:

There are no mode bits, so every file reads as 0644. That means chmod +x inside the sandbox doesn't show up in the diff on Windows. It's documented, and nothing to fix.
A read-only attribute makes the replace fail with access denied. The applier clears the attribute and tries again (and puts it back if the retry fails too). Undo restores the old file.
Junctions (Windows folder links) are reported in the review but never followed, the same way symlinks are handled elsewhere.
Long paths: every path handed to the wide-character Win32 calls gets the \\?\ prefix once it nears the old 260-character limit.
CRLF line endings have to survive the round trip through the Linux container untouched. A .gitattributes also keeps the agent image files and shell scripts on LF, so Git's checkout on the runner doesn't rewrite them.

7. PowerShell eats `--`

The smoke test runs mudroom new <project> --agent smoke -- cmd /c exit. When that line went through a PowerShell helper function, the bare -- vanished. PowerShell treats -- as its own end-of-parameters marker. Mudroom then saw cmd /c exit as stray arguments. The fix is to build the arguments as an array and pass the array, so PowerShell doesn't parse them.

8. What CI can and can't test

GitHub's Windows runners can't run Linux containers by default, so for a while nothing tested a real sandbox. It turns out windows-latest runs on hardware with nested virtualization, so WSL 2 and a Podman machine work there. CI now builds the agent image with Podman, runs the network check and a short real session, then diffs and applies the result.

Two things are still open, and I'd rather say so:

Locked network mode on Windows. That's the default, where the only way out of the sandbox is an allowlist proxy on the host. It hasn't passed in CI yet: on the runner's rootless Podman machine, the network check hangs. The open-network mode works. I'm working on a fix.
Docker Desktop on a real PC. It hasn't been tested yet. The arm64 runner can't run a VM at all, so on arm64 only the zip and the smoke test run in CI.

One Podman detail for anyone else trying this: the runner's Podman machine had no pids cgroup controller, and containers failed with "controller pids is not available". Setting pids_limit = 0 in the machine's containers.conf fixes it.

Try it

scoop bucket add kernel-hunter https://github.com/Kernel-Hunter/scoop-bucket
scoop install mudroom

There are also plain zips on the release page, and a winget package is in review. You'll need Docker Desktop or Podman. If you run it on a real Windows machine, especially with Docker Desktop, I'd like to hear how it went, good or bad: open an issue.

Why my Mac memory app doesn't try to empty your RAM

Karim Masmoudi — Sat, 10 Oct 2026 13:57:28 +0000

Most Mac cleaners show you a big number and offer to make it smaller. That number is usually cached memory, which macOS is putting to good use, and shrinking it makes your Mac slower, not faster.

I wanted a tool that tells me what's actually going on, so I built Boost, a free and open source menu bar app for memory and disk space.

What "free memory" can mean on macOS

On Windows, tools like Mem Reduct call EmptyWorkingSet, which lets one process push another process's pages out to the pagefile. macOS has no public equivalent, as Apple's kernel source shows. It wouldn't help much anyway: macOS compresses memory before it swaps, and reading a compressed page from RAM is much faster than reading it back from the SSD.

So Boost uses what macOS does offer. Free Memory runs Apple's own memory_pressure tool, which nudges the kernel to release idle pages and compress what it can. Boost takes readings before and after and reports only what actually stopped being used. It doesn't close apps, delete files or ask for a password, and it stops early if swap starts growing.

On a typical run that's a few hundred MB to around a gigabyte. If your Mac isn't short on memory, there's little sitting idle to give back, and the header says your Mac is coping instead of inventing work. Settings has an aggressive mode that asks harder. It's off by default, because pushed far enough the kernel may kill something on its own.

Pausing instead of quitting

The feature I use most is Pause. Boost freezes an app and its helper processes with SIGSTOP, so it uses no CPU and keeps its state, and resumes it with SIGCONT. You can pick apps to pause automatically after 5 to 60 minutes in the background, and Boost wakes each one the moment you switch to it.

Two things keep this from going wrong. If Boost crashes or is killed, a small watchdog resumes everything it froze, so nothing stays stuck. And a hard-coded list of system processes (Dock, WindowServer, Finder, loginwindow and a few more) can never be paused, because freezing those freezes the desktop.

Disk cleanup that refuses the risky parts

The Disk tab lists only caches that the tool that made them will rebuild: Homebrew, npm, pip, uv, Cargo, Gradle, Xcode DerivedData, simulator caches, app caches and logs. It won't touch Downloads, node_modules found by name, or iOS backups. Nothing is ticked for you.

Every removal goes through two checks: an allowlist of what may be scanned, and a second check of the resolved path right before deleting. A symlink inside a cache that points at your documents is how tools like this destroy data, and there's a test that builds exactly that trap.

Projects (old node_modules, Rust target, SwiftPM .build, virtualenvs) and Uninstall move things to the Trash, with Undo.

The rest

History: a reading every minute, kept for a week, charted over 2 hours, 24 hours or 7 days, with the peak, the average and how many times the Mac went into swap.
Alerts when swap passes 1, 2 or 4 GB, or when memory stays tight for a full minute, naming the app using the most. A spike that passes on its own is ignored.
Process sampling is native (sysctl and libproc). Shelling out to ps cost 111 ms per refresh and kept idle CPU near 20%.
No analytics, no telemetry, no update check, no network access at all.

Try it

brew install --cask kernel-hunter/boost/boost

Or build it from source with Command Line Tools; Xcode isn't needed. macOS 14 or later, Apple silicon and Intel, GPL-3.0. It's signed with a local certificate rather than notarized, and the cask clears the quarantine flag.

There's also a 30-second overview video with sound.

I'd like to hear what a memory tool should show you when there's nothing to fix.

Kernel-Hunter / boost

A memory and disk utility for macOS that tells you the truth. Pause apps instead of closing them, reclaim disk space that is genuinely safe to reclaim.

Boost

A free, open source Mac app for memory and disk space. It lives in your menu bar, shows what is using your RAM, freezes apps you are not using, and finds caches and leftovers that are safe to remove.

If you have looked at CleanMyMac, iStat Menus or AppCleaner and did not want a subscription, this covers the parts most people actually use.

brew install --cask kernel-hunter/boost/boost

Or build it yourself, which takes about as long and involves no Gatekeeper at all:

git clone https://github.com/Kernel-Hunter/boost.git
cd boost && ./Scripts/build.sh

macOS 14 or later, Apple Silicon and Intel, one universal binary. It builds with Command Line Tools, so Xcode is not required. If Boost is useful to you, a star helps other people find it.

On signing. Boost is signed with a local certificate, not notarized because notarizing needs a paid Apple Developer account. A downloaded .zip will be stopped…

View on GitHub

I run Claude Code with permission prompts off, so I put it in a VM

Karim Masmoudi — Sat, 10 Oct 2026 13:29:00 +0000

I use Claude Code every day, and I run it with permission prompts off. It's much faster that way. You give it a task, go do something else, and come back to a finished change.

The downside is finding out afterwards what else it did. Git can bring back tracked files, but not untracked or ignored ones, and not anything outside the repo.

Most agent sandboxes I tried mount the project folder into a container or VM read-write. That stops the agent from touching the rest of my Mac, but its changes still land in my real files as it works. By the time I look, they're already there.

So I built Mudroom, a free and open source Mac app and CLI that keeps the agent off the real folder completely.

How it works

Mudroom makes an APFS copy-on-write clone of the whole project folder, untracked and ignored files included. The clone takes no extra disk until files change.
It boots a Linux micro-VM with Apple's container tool and mounts only the clone. Your real folder is never mounted.
Claude Code, Codex, Gemini CLI, opencode, Aider or any command runs inside, in a normal Terminal window, so you can still talk to the agent.
When the agent exits, you get a diff that looks like a pull request: added, modified, deleted and permission changes, file by file. Modified files have a checkbox per hunk.
You apply everything, some files, or single hunks. Every apply can be undone. If you edited a file yourself while the agent was running, it's flagged and never overwritten.

The same thing from the command line:

mudroom run ~/code/myapp -- claude --dangerously-skip-permissions
mudroom diff last
mudroom apply last --all
mudroom undo last

The network part

By default the VM sits on a host-only network with no DNS and no route out. The only way out is a logging proxy that lets through the agent's own API hosts (for Claude Code that's api.anthropic.com and a few sign-in hosts) plus anything you add.

The review screen has a Network tab that lists every host the VM tried to reach, blocked ones first. If something legitimate got blocked, one click adds it to the project's allowlist for the next run. mudroom network check tries to get around the proxy from inside the VM and prints what it could and couldn't reach.

Signing in once

mudroom agent login claude (or "Use my Claude account" in the app) runs claude setup-token and stores the token in the macOS Keychain, so later sessions start signed in. Your real ~/.claude is never mounted. ANTHROPIC_API_KEY works too.

What it doesn't do yet

I'd rather list these up front:

The app and the VM need macOS 26 or later on Apple silicon. Linux and Intel Macs get a CLI-only build on Docker or Podman, which is a container, not a VM.
The VM can reach services on your Mac that listen on 0.0.0.0. The network check reports it. I don't have a fix yet.
While a session runs, Apple's container runtime keeps the session environment, tokens included, in a config file that any process running as you can read.
The allowlist works on host names. There's no TLS inspection.
The app isn't notarized. The install script and Homebrew cask clear the quarantine flag.
Lockfiles and generated files make noisy diffs. It's early.

If your project is a git repo and you're happy reviewing with git, Docker Sandboxes' clone mode gets you close. Mudroom also covers untracked and ignored files, folders that aren't repos, and gives you a review screen and an undo for each apply.

Try it

brew install --cask kernel-hunter/tap/mudroom

or the one-line install script in the README. There's also a 33-second overview video with sound.

It's MIT licensed and free. I'd like to hear from people who run agents unattended:

Is the end of the run the right time to review, or would you want checkpoints in the middle?
How should generated files and lockfiles show up in the diff?
Which agents or setups should I test next?

Kernel-Hunter / mudroom

Run coding agents in a Linux VM on a clone of your project, then review and apply their changes like a pull request

Mudroom

Run coding agents in a sandbox, then review their changes like a pull request before anything touches your project.

Coding agents work best with permission prompts turned off, and that means they can delete files or reach any host while you aren't looking. Mudroom runs Claude Code, Codex, Gemini CLI, opencode, Aider (or any command) in a Linux micro-VM, on a copy-on-write clone of your project, with network access limited to the hosts you allow. Your real folder is never mounted. When the agent is done you read the diff, apply all of it, some files, some hunks or none, and undo any apply later.

macOS app and CLI on Apple-silicon Macs. CLI only (with Docker or Podman) on Linux and Intel Macs.

Status: early prototype. Expect rough edges and breaking changes.

Watch the 33-second overview (with sound)

Quick start

Install (Apple-silicon Mac, macOS 26 or later):
```
curl -fsSL
```
…

View on GitHub

I built my portfolio as an operating system, with no framework

Karim Masmoudi — Fri, 18 Sep 2026 18:09:56 +0000

A CV is a list of claims. An operating system is a thing you can use. That's the whole premise behind KM/OS, my portfolio: instead of a page that tells you I can build things, it's a desktop OS running in a browser tab: windows, a dock, a real virtual filesystem behind a Terminal app, a menu bar where every section of a normal portfolio is an application that actually works.

No framework, on purpose

Vanilla JavaScript in ES modules, bundled by esbuild into a single file. Hand-written CSS over one set of design tokens. Two dependencies total, and both only at build time.

For an interface built almost entirely from bespoke pieces (custom window chrome, custom drag/resize physics, a custom terminal emulator), a framework would have added a runtime, a build step, and a set of conventions in exchange for very little the project actually needed. A few decisions that came out of that:

Windows are cloned from a <template> and driven by state classes, so all the open/close/minimize motion lives in CSS, not JS.
Pointer Events handle every gesture (drag, resize, swipe), so behavior is identical across mouse, pen, and touch without separate code paths.
One virtual filesystem is shared by the Terminal, a Finder-style file explorer, and a notes app. Edit a file in one, and it changes in the others.
A service worker uses content-hashed bundle URLs (app.js?b=<build-id>, regenerated every build). This came from a real bug: a stale cached bundle once ran against a freshly-deployed HTML document and silently broke the mobile UI, because the old JS was looking for DOM nodes the new shell no longer had. Giving the bundle's address a build id, not just its cache headers, means a stale cache has nothing to serve at a URL it's never seen.

What leaves the browser

Worth being explicit about, since it's a portfolio and not a toy: only two things call out to anything else. A question typed into the built-in AI assistant goes to the site's own server, then to a language-model provider. The API key never reaches the browser. The contact form posts to a forwarding service. Everything else is same-origin, enforced by a real Content-Security-Policy HTTP header (not a meta tag: meta tags can't express frame-ancestors), which is also why there's no analytics script and no font CDN.

Two inline <script> tags that do need to run are pinned by SHA-256 hash instead of unsafe-inline, and there's a test that recomputes both hashes from the HTML source and fails the build loudly if either script's content ever changes without the hash being updated. That's a tripwire against the failure mode where an edited script just silently stops executing in production with zero build error.

There's a public chat room too, which is the one place text from strangers gets rendered back to other visitors. Messages are length-capped, stripped of control characters, rate-limited server-side, and always written into the DOM as text content, never as markup.

The part I didn't expect to spend time on: GEO

Once the site worked, the next problem was that nobody could find it: a name search for "Karim Masmoudi" is dominated by an unrelated, actively-covered public figure with years of accumulated backlinks. That's not a code problem. But there was a real code problem hiding next to it: the site was shipping noindex, nofollow on every page, which meant none of the SEO work mattered until that came off first.

After that, the more interesting part was optimizing for something that barely existed as a discipline a year ago: being cited by AI answer engines (ChatGPT, Perplexity, Google AI Overviews), not just ranked by classic search. Concretely:

A FAQPage JSON-LD block, but built from real, already-written content rather than freehand copy: I split the AI assistant's own one-paragraph bio into sentences and mapped them to its own suggested questions, so the "answers" are literally the same facts the assistant already gives a human visitor.
llms.txt and /.well-known/ai.txt, /ai/summary.json, /ai/faq.json: the GEO-era equivalents of robots.txt, generated at build time from the same data files, not maintained by hand.
A JSON-LD @graph where entities reference each other by @id (Person → CollegeOrUniversity → WebSite) instead of nesting everything inline, since that's what lets a search engine resolve "who is this person" as a connected set of facts instead of a string that happens to appear on a page.
dateModified sourced from git log -1, not a hardcoded string that silently goes stale.

The one thing I deliberately didn't add: a SearchAction schema advertising site search to Google, because the site doesn't support URL-parameter search deep-linking. A rich-result annotation for a capability that doesn't work is worse than no annotation at all.

DEV Community: Karim Masmoudi

Shipping a Swift CLI on Windows: what broke

1. The C++ headers refuse the compiler

2. There's no static standard library

3. A socket is not a file descriptor

4. The 503 that never arrived

5. Atomic writes meet antivirus

6. Files don't work the way Unix code expects

7. PowerShell eats --

8. What CI can and can't test

Try it

Why my Mac memory app doesn't try to empty your RAM

What "free memory" can mean on macOS

Pausing instead of quitting

Disk cleanup that refuses the risky parts

The rest

Try it

Kernel-Hunter / boost

A memory and disk utility for macOS that tells you the truth. Pause apps instead of closing them, reclaim disk space that is genuinely safe to reclaim.

Boost

I run Claude Code with permission prompts off, so I put it in a VM

How it works

The network part

Signing in once

What it doesn't do yet

Try it

Kernel-Hunter / mudroom

Run coding agents in a Linux VM on a clone of your project, then review and apply their changes like a pull request

Mudroom

Quick start

I built my portfolio as an operating system, with no framework

No framework, on purpose

What leaves the browser

The part I didn't expect to spend time on: GEO

7. PowerShell eats `--`