On August 18, the hp-laser-1008a-macos repository made an HP printer work on a Mac by hiding a small Linux system inside macOS. CUPS sent raster data to a root daemon, Colima ran HP's proprietary rastertospl codec, and libusb delivered the resulting stream to the printer.1
That architecture was strange enough to make a good headline, and Tom's Hardware described essentially that version: Claude Code, a Linux codec, a container and finally normal Cmd-P printing from any application.6 By the time the repository settled into its current form, nearly every unusual layer in that description had been removed.
Its Git history puts the first implementation at 00:02 on August 18. At 14:13 on August 19, roughly 38 hours later, Kuber Mehta removed Docker, Colima and HP's proprietary Linux driver in favor of patched SpliX. Twenty-four minutes after that, Python, pyusb and libusb disappeared too, replaced by a C helper using IOKit. By 15:33, the localhost socket and LaunchDaemon were unnecessary because the USB helper had become a CUPS backend running with the required privileges.1
So the useful story is not “Claude wrote a driver.” It is how quickly a compatibility hack was taken apart once the project understood the printer better.
38 hours
The original request could hardly have been smaller: set up the drivers for this connected HP Laser 1008a.2
Mehta's published transcript contains 45 user turns, 200 Claude Code responses and 176 tool calls. IRZ counted those directly from the JSON embedded in the transcript page: 132 Bash calls, 28 file writes, six web fetches, five searches and five edits. Mehta describes the initial session as about four hours with Claude Opus 4.8.2
The transcript reads much more like an ordinary hardware debugging session than one-shot generation: try the generic path, notice that CUPS sees the device but cannot print, send data directly, watch striped pages come out, photograph them, change the hypothesis and try again.2
At one point the user reports that it printed “something” four or five times in a row; later the printer itself produces an SPL Illegal Resolution error, two physical clues that the device is accepting the stream without understanding it correctly.2
The first working solution takes the shortest route: reuse the component that already speaks the printer's language. HP ships rastertospl for Linux, so the project runs that codec inside Colima and keeps the rest of the integration on macOS.12
It prints, which is enough to keep investigating, but running a background Linux VM every time the family needs an A4 page is a fairly ugly place to stop.
The false codec
The Linux detour could easily have survived for years because it worked, and for a family printer a background VM consuming around two gigabytes was absurd but still tolerable.
Then an adversarial review mentioned in the transcript pushed the project back toward SpliX. Support for the HP Laser 10x family had recently landed upstream; the remaining problem was no longer total lack of support, but the fact that SpliX output still caused the repeated striped pages.128
The next useful clue comes from feeding an identical raster through HP's binary and SpliX, then comparing the streams: their bands use the same 4864 × 128 dimensions and compression mode 0x11, which moves the investigation toward the page header: HP emits 2480 × 3507, geometry on a 300-dpi grid, while SpliX emits 4960 × 6912, effectively treating the page dimensions as a 600-dpi value.1
The 1008a firmware interprets that second header as a physically huge page, so it places a band, reaches the real edge of the A4 sheet, ejects, and continues because the logical page still appears unfinished.1
The local fix is a 26-line diff, with roughly ten lines changing the logic: SpliX's existing 300-dpi geometry path is also enabled when specialBandWidth() identifies this printer family, while the band rendering remains unchanged.1
Once that behaviour is understood, HP's proprietary binary no longer needs to remain in the runtime; it served as an oracle for the format and can then be removed.
Docker leaves
The pipeline gets shorter very quickly after that. The first version: CUPS produces a raster, a localhost socket hands it to a root daemon, the daemon starts rastertospl in Colima, receives SPL3 and sends it over USB with Python/libusb.1
Next version: CUPS calls rastertoqpdl, the SpliX filter compiled with the 300-dpi patch, while a privileged helper still handles USB.1
Current version: the SpliX filter remains, but the C helper itself becomes a CUPS backend, installed root-owned with mode 0700. CUPS therefore executes it with the privileges it needs, and the backend opens the USB interface through IOKit and calls WritePipe directly.1
One more annoying detail appears after that: the printer exposes both a classic printer-class USB mode and IPP-over-USB; macOS can leave it on the second, where the device expects HTTP framing and silently ignores raw SPL3, so the backend reads the USB configuration descriptor and forces the classic alternate setting before writing.1
Even after learning the correct printer language, the project still has to put the USB interface back into the correct software dialect.
HP contradicts HP
The official documentation adds a small absurdity: HP's current driver-download page for the 1008a offers Windows 7, 8, 10, 11 and Linux, with no macOS option in the operating-system selector.3 Another HP specifications page lists Catalina, Big Sur, Monterey, Ventura and Sonoma as compatible operating systems, then gives a support note that reads “Windows 10 or higher.”4
So IRZ cannot turn “HP never shipped a working Mac driver” into a perfectly clean administrative fact. We can verify something narrower: the current download page does not offer macOS, the developer says he could not find a working driver, and the transcript shows the test Mac with no suitable model available in CUPS.123
Software repairability gets very concrete here: the hardware exists, one product page promises support, the actual software catalog says something else, and the user learns which statement matters only after plugging in the cable.
Still legacy
To be sure, the current version remains fairly legacy itself, using a PPD, a classic CUPS filter and a backend. OpenPrinting has deprecated this driver model and wants older devices moved behind Printer Applications, programs that present themselves as modern IPP printers while translating internally to the legacy protocol.5 The project's roadmap plans exactly that move but treats it as a substantially larger project with little immediate benefit over the working driver.1
A DriverKit version would look more like something Apple expects today, using a signed USB system extension. The repository stops short for concrete reasons: full Xcode, a paid Apple Developer identity, an approved DriverKit entitlement and matching provisioning are required.1
Software repair therefore reaches another wall after the proprietary protocol: modern platforms deliberately make improvised low-level drivers harder to install.
Where is Claude?
The transcript makes the autonomous-generation version of the story difficult to sustain even though Claude Code does a great deal of work, writing scripts, searching protocols, changing code and proposing hypotheses. Mehta keeps supplying what the agent cannot own: the physical printer, power cycles, photographs, bad pages, error messages, the decision to continue and, at one point, an adversarial review from another LLM.2
The Register reports roughly 30 to 40 prompts and about four percent of Mehta's monthly usage, while noting that he knew little about macOS drivers before the session.7 Our extraction of the published transcript finds 45 user turns, several of which are simply photos or copied command output from the machine.
The underlying reverse-engineering ingredients have not changed much: documentation, existing open-source work, binary comparison, physical experiments and a lot of failed attempts. What the agent changes is the entry cost of connecting those pieces quickly enough that someone who only wanted to print keeps going instead of giving up.
And perhaps the best sign of success is not how much code Claude produced. It is that, in less than two days, a large portion of the first implementation could already be deleted.