Zed's remote server now runs on FreeBSD via a uname spoof and a Linuxulator fix

Running Zed's remote development server on FreeBSD is now possible, though it takes two unconventional ingredients: FreeBSD's Linux binary compatibility layer and a wrapper script that misreports the operating system to Zed. The recipe, laid out in a blog post by Hayzam that surfaced on Hacker News's front page, also documents a FreeBSD kernel regression the author diagnosed and fixed along the way — a patch already headed for FreeBSD 15.2-RELEASE.

A faster editor where AI is opt-in

The post starts with motive: after nearly ten years on VS Code, the author finds the editor slow and increasingly crowded with AI features. A commenter pointed out that VS Code ships chat.disableAIFeatures, which the author tested and found does disable the built-in assistant, but the editor still feels heavy. Zed, by contrast, is fast and has long offered a first-class kill switch for its AI features, either as a Settings toggle or "disable_ai": true in the config file.

The author does not avoid language models entirely; harnesses such as OpenCode handle regression testing, edge cases and open-ended exploration. The objection is specifically to an assistant embedded in the editor, poised over every line of code.

Making Zed believe it is talking to Linux

Zed ships no FreeBSD remote server, but FreeBSD runs Linux binaries, so the post uses Zed's Linux build. The steps:

• Enable Linux compatibility with sysrc linux_enable=YES, start the service, install the linux_base-rl9 package, and confirm the linux64 module is loaded via kldstat.
• Zed asks the host which platform it runs; FreeBSD amd64 gets no matching download and the client gives up. The workaround is a small shell script saved as ~/.local/bin/uname that replies "Linux x86_64" when Zed asks for the kernel name and hardware (uname -sm or -ms) and forwards every other invocation to the real /usr/bin/uname.
• Because remote connections use non-interactive SSH sessions, ~/.local/bin must be added to PATH in ~/.zshenv (or the shell's equivalent), not just the interactive rc file.
• Connect from Zed over SSH; the first connection uploads the Linux server to ~/.zed_server/ on the FreeBSD host, with logs under ~/.local/share/zed/logs.

The author calls the spoof a contained lie, and the part of the setup most worth retiring once upstream support exists.

The kernel bug behind an empty file tree

With the wrapper in place, connections succeed but the project tree comes up empty, and the server log shows directory reads failing with an "Invalid argument" error (os error 22). According to the post, the culprit is a regression from a February 2026 fix for bogus NFS directory entries (PR 292282): the Linux compatibility layer began rounding every directory-read request up to a 512-byte block before performing the native FreeBSD read.

When a caller requests a buffer that is not a multiple of 512 — Zed's server uses 768 bytes — the rounded-up native read can produce more entries than the caller's buffer holds. The emulation layer stops translating once an entry no longer fits and returns EINVAL, but the underlying directory offset has already advanced past the entire native batch. Returning a partial batch is not a fix by itself: in a test of a lenient variant, 112 files out of 1,002 silently vanished from a project listing. Zed, seeing the error, rendered folders as empty, which the author considers better than a quiet loss.

The patch

The fix (commit ec6629628cb, review D60760) rounds the buffer up only when a request is smaller than one 512-byte block, and otherwise caps it at MAXBSIZE as before. The change is safe because Linux directory records are never larger than FreeBSD's — the dirent64 header is 19 bytes versus 24, and both align records to 8 bytes — so any native batch that fits the caller's buffer also fits after translation.

The first version of the patch fixed only getdents64; extending it to the legacy getdents path for 32-bit and 64-bit callers dropped the author's test matrix from 86 failures to zero. The change is merged to main, stable/15 and releng/15.2, so 15.2-RELEASE will include it. It was reviewed by FreeBSD developers Kyle Evans and Mark Johnston, and the author notes it reached the release branch faster than most patches.

Why it matters

The post looks like a curiosity but points at two broader threads. One is the appetite for editors that are fast by default and treat AI assistance as opt-in rather than ambient — the complaint is not about language models, but about editors that embed them in every keystroke. The other is the state of FreeBSD's Linux emulation: capable enough to run a production remote-development server unmodified, yet fragile enough that a subtle buffer-sizing regression in the kernel showed up only as an empty file tree. With the fix landing in 15.2, Zed remote development on FreeBSD becomes a one-wrapper setup rather than a kernel debugging exercise, and editor projects weighing BSD support have a working blueprint.