--- title: "The ‘Claude driver’ deleted Docker in 38 hours" locale: "en" url: "https://irz.fr/en/articles/hp1008-macos-driver-evolution-en" markdown_url: "https://irz.fr/en/articles/hp1008-macos-driver-evolution-en.md" category: "tech" tags: ["macOS", "printer", "CUPS", "Claude Code", "reverse engineering", "SpliX", "software repair"] published_at: "2026-08-21T08:54:00.000Z" author: "Camille Morel" translation: "https://irz.fr/fr/articles/hp1008-macos-driver-evolution-fr.md" --- # The ‘Claude driver’ deleted Docker in 38 hours The first working hack ran HP's Linux codec inside Colima. Thirty-eight hours later, the repository had removed it in favor of patched SpliX and a native CUPS USB backend. 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](https://github.com/Kuberwastaken/hp-laser-1008a-macos) 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](https://www.tomshardware.com/tech-industry/artificial-intelligence/dev-uses-claude-ai-to-create-native-macos-driver-for-obscure-windows-only-printer-linux-container-hack-enables-system-wide-cmd-p-printing-driver-now-available-on-github) 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](https://github.com/Kuberwastaken/hp-laser-1008a-macos) 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](https://cdn.kuber.studio/chat/hp-laser-1008a-driver) 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](https://cdn.kuber.studio/chat/hp-laser-1008a-driver) 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](https://cdn.kuber.studio/chat/hp-laser-1008a-driver) 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](https://cdn.kuber.studio/chat/hp-laser-1008a-driver) > Illustration: Page with repeated black raster stripes printed by the HP Laser 1008a before the SPL3 format fix. Before the fix, SpliX produced a striped fragment near the top of the sheet and the printer continued ejecting pages. The symptom eventually pointed back to page geometry in the SPL3 header. Credit: [Kuber Mehta / hp-laser-1008a-macos](https://github.com/Kuberwastaken/hp-laser-1008a-macos). 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.[1](https://github.com/Kuberwastaken/hp-laser-1008a-macos)[2](https://cdn.kuber.studio/chat/hp-laser-1008a-driver) 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.[1](https://github.com/Kuberwastaken/hp-laser-1008a-macos)[2](https://cdn.kuber.studio/chat/hp-laser-1008a-driver)[8](https://github.com/OpenPrinting/splix/commit/206e283) 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](https://github.com/Kuberwastaken/hp-laser-1008a-macos) 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](https://github.com/Kuberwastaken/hp-laser-1008a-macos) 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](https://github.com/Kuberwastaken/hp-laser-1008a-macos) > **The bug was two page sizes** > Comparison between the 300 dpi page header expected by the HP Laser 1008a and the 600 dpi dimensions previously emitted by SpliX. > - Same 600 dpi raster, two header geometries > - HP rastertospl > - 2480 × 3507 300 dpi grid > - SpliX before patch > - 4960 × 6912 600 dpi value > - The firmware reads page geometry on a 300 dpi grid even while raster bands remain 600 dpi. > The raster content was not the main fault. The header made the firmware believe the page was almost twice as large in each dimension. 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](https://github.com/Kuberwastaken/hp-laser-1008a-macos) Next version: CUPS calls `rastertoqpdl`, the SpliX filter compiled with the 300-dpi patch, while a privileged helper still handles USB.[1](https://github.com/Kuberwastaken/hp-laser-1008a-macos) 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](https://github.com/Kuberwastaken/hp-laser-1008a-macos) > **Four runtime layers disappear in 38 hours** > Timeline showing the project moving from HP's codec inside Colima to patched SpliX and a native CUPS backend. > - Aug 18 → Aug 19: the hack becomes much smaller > - 00:02 · CUPS → socket → daemon → Colima/Linux → HP rastertospl → libusb > - +38 h 11 · patched SpliX replaces Colima + HP codec > - +24 min · IOKit replaces Python + pyusb + libusb > - The CUPS backend then removes the localhost socket and LaunchDaemon as well. > IRZ reconstructed the timeline from the repository commits. The first version already printed; later commits progressively remove layers that are no longer necessary. 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](https://github.com/Kuberwastaken/hp-laser-1008a-macos) 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](https://support.hp.com/in-en/drivers/hp-laser-1000-printer-series/model/2101513671) 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](https://support.hp.com/us-en/product/details/hp/2101513878) 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.[1](https://github.com/Kuberwastaken/hp-laser-1008a-macos)[2](https://cdn.kuber.studio/chat/hp-laser-1008a-driver)[3](https://support.hp.com/in-en/drivers/hp-laser-1000-printer-series/model/2101513671) 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](https://openprinting.github.io/cups/drivers.html) 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](https://github.com/Kuberwastaken/hp-laser-1008a-macos) 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](https://github.com/Kuberwastaken/hp-laser-1008a-macos) 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](https://cdn.kuber.studio/chat/hp-laser-1008a-driver) 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](https://assets.theregister.com/2026/08/19/202616/) 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. ## References 1. [Kuber Mehta, hp-laser-1008a-macos, GitHub repository](https://github.com/Kuberwastaken/hp-laser-1008a-macos) 2. [Kuber Mehta, Teaching macOS to natively print to the HP Laser 1008a, Claude Code transcript, August 17 2026](https://cdn.kuber.studio/chat/hp-laser-1008a-driver) 3. [HP, Laser 1008a — Software and Driver Downloads](https://support.hp.com/in-en/drivers/hp-laser-1000-printer-series/model/2101513671) 4. [HP, Laser 1008a — Product specifications](https://support.hp.com/us-en/product/details/hp/2101513878) 5. [OpenPrinting, Printer Applications and Printer Drivers](https://openprinting.github.io/cups/drivers.html) 6. [Tom's Hardware, Dev uses Claude AI to create native macOS driver for obscure Windows-only printer, August 19 2026](https://www.tomshardware.com/tech-industry/artificial-intelligence/dev-uses-claude-ai-to-create-native-macos-driver-for-obscure-windows-only-printer-linux-container-hack-enables-system-wide-cmd-p-printing-driver-now-available-on-github) 7. [The Register, Dev taps Claude Code to craft custom printer driver for macOS, August 19 2026](https://assets.theregister.com/2026/08/19/202616/) 8. [OpenPrinting SpliX, HP Laser 10x support, commit 206e283](https://github.com/OpenPrinting/splix/commit/206e283)