Claude Code Wrote a macOS Driver for an HP Printer That Never Had One

On August 17, 2026, a developer named Kuber Mehta posted something unusual on X: a complete, lightly-redacted transcript of a 4-hour Claude Code session in which an AI agent made an obscure Windows-only printer work natively from Cmd-P on macOS — a printer HP never shipped a Mac driver for.

The post blew up. Then the GitHub repo (github.com/Kuberwastaken/hp-laser-1008a-macos) hit Hacker News. The HN thread delivered what HN always delivers: a brutal adversarial code review, answered with a clean-room A/B test.

This is the story of that session — and what it says about AI agents doing work that used to take driver engineers weeks.

The problem: a printer that only speaks Samsung

The HP Laser 1008a is a cheap, rebadged Samsung host-based laser printer. “Host-based” means it’s a dumb device: the computer must rasterize everything into raw compressed scanlines and push them over the wire in SPL3 (Samsung Printer Language 3 / QPDL v3), a proprietary format.

• No macOS driver — HP never shipped one for this family
• No AirPrint — not even driverless IPP
• No PostScript, no PCL — generic drivers can’t talk to it

On an Apple Silicon Mac, the device is effectively bricked. Prior attempts all failed:

The 4-hour journey

Step 1: The false-offline trap

Claude added the printer with the generic PCL driver. The job hung at connecting-to-device and CUPS reported the printer offline. Digging with ioreg, Claude found the real culprit: the printer exposes bInterfaceProtocol = 4 — IPP-over-USB (AirPrint-over-USB mode). The macOS raw USB backend misreads that status byte as “permanently busy,” wedging the device in STATUS:BUSY until a power cycle.

Step 2: The macOS sandbox wall

On macOS 26, only root processes can talk to raw USB interfaces — and CUPS print filters are strictly sandboxed, blocked from raw USB entirely. Claude’s answer: a standalone root-level Python script (direct_write.py) using PyUSB/libusb to claim Interface 0 / Alternate Setting 0 (classic raw bidirectional printing), detach the Apple kernel driver, and write directly to bulk OUT endpoint 0x02. Transport solved: 56,738 bytes pushed cleanly.

Step 3: The printer teaches Claude its own language

Raw transport alone wasn’t enough — the open-source encoder produced garbage. Claude compiled foo2qpdl from foo2zjs and the printer responded by printing a crisp, legible self-diagnostic error page:

SPL ERROR - Please use the proper driver at POSITION: 0x2000 (8192)

0x2000 is exactly where the first compressed raster scanline begins — the printer parsed the PJL headers but choked on the compression. A second test at 1200x600dpi produced Illegal Resolution. The hardware was literally telling Claude what it wanted: 600x600dpi, and an encoder it could decode.

Step 4: Containerizing HP’s real codec

The printer demanded “the proper driver” — which HP distributes as an arm64 Linux binary (rastertospl) inside the HP Unified Linux Driver. Claude booted Colima (a lightweight ARM64 Linux VM for macOS), built an Ubuntu container with HP’s proprietary rastertospl + libscmssc.so, fed it standard CUPS raster via stdin, and got genuine vendor-compiled SPL3 back on stdout. Pushed through direct_write.py — a flawless page printed.

Step 5: Wiring it into Cmd-P (the CUPS socket bypass)

The final challenge: CUPS’s hardened sandbox blocks custom filters from running docker or even logging. Claude’s elegant solution — split the architecture:

macOS App (Cmd-P)
      │
      ▼
CUPS Print Queue (renders uncompressed raster)
      │
      ▼
CUPS Socket Backend → 127.0.0.1:9108   ← sandbox-blessed localhost stream
      │
      ▼
hpl1008-daemon (root LaunchDaemon)
      │  (streams CUPS raster via stdin)
      ▼
Colima Linux ARM64 Container (hp-spl)
   └── HP proprietary rastertospl + libscmssc.so
      │  (SPL3 via stdout)
      ▼
direct_write.py (root PyUSB/libusb, endpoint 0x02)
      │
      ▼
HP Laser 1008a ✅

CUPS’s built-in JetDirect socket:// backend is already sandbox-blessed for localhost network streams — so the daemon listens on port 9108, receives raster, streams it through the container, and pushes SPL3 to the printer. Native Cmd-P printing, reboot-safe (LaunchDaemon), delivered as a one-command MIT-licensed installer.

The HN gauntlet: review → A/B test → verdict

HN delivered its trademark adversarial review:

1. “splix 2.0.2 fixed this” — the reviewer noted SpliX 2.0.2 (July 2026) added HP Laser 10x support with QPDLVersion 3, forced 512-byte packets, and a Samsung-matching bandwidth table
2. Daemon critique — the 2-second silent timeout for job framing is fragile; use TCP EOF boundaries instead
3. Hardcoded USB PID (0x069E) — excludes the 1003/1006 siblings

The author’s response was the best kind of science: a clean-room A/B test. Claude compiled splix 2.0.2 natively on macOS, verified the new bandwidth logic engaged (608-byte bandwidth for A4), and fed the raw QPDL-v3 output through the same USB writer.

Result: total failure. Garbled scanlines again. The vendor codec’s compression encoding is simply not replicated by the open-source drivers — the containerized official codec was the necessary path.

What this means for the future of driver work

This session is a genuine milestone for AI agents:

• Reading protocols from device behavior — the printer’s own error pages became documentation
• Navigating OS security models — sandbox analysis, root daemons, socket bypasses
• Orchestrating heterogeneous toolchains — macOS + Linux VM + container + vendor binaries
• Iterating on hardware feedback — physical pages as test output, ~4 hours of loop-closing

Traditionally, this was weeks of specialized driver engineering: reverse-engineering a proprietary raster format, fighting macOS sandboxing, and packaging an installer. One agent, one session, one afternoon — then published MIT-licensed for the world.

The printer still can’t AirPrint. But it now works from Cmd-P on any Mac — because an AI agent decided “no driver exists” wasn’t an answer. 🖨️