An agent shipped the HP printer driver HP would not: four hours, and a root daemon to maintain

Kuber Mehta asked Claude Code to install a printer driver on a family Mac, and roughly four hours later, on August 17th, had a working path from Cmd-P to an HP Laser 1003, 1006 or 1008 on Apple Silicon ^[1][2][4]. The interesting part is not the printer. It is that an agent closed a driver-layer gap that HP's own current driver-download page does not offer to close, since that selector lists Linux and several Windows versions and no macOS option at all ^[11].

The obvious approach failed first, which is the useful detail. Claude Code detected the USB device, inspected the available CUPS drivers and installed a generic PCL configuration, which stalled because the 1008a is Samsung-derived hardware that speaks Samsung Printer Language and expects the host to generate a device-specific raster stream ^[5][6]. Generic drivers left the device offline; the open-source foo2zjs encoder made the printer emit an error page asking for the proper driver; SpliX 2.0.2, which recently added support for related HP Laser models, produced striped, repeated pages ^[7].

The path that worked reuses HP's own `rastertospl` binary from its Unified Linux Driver, which cannot run on macOS, so the installer puts it inside an ARM64 Linux container managed by Colima ^[8]. A macOS CUPS queue converts application output to CUPS raster and hands it to a local socket; a root LaunchDaemon takes the job, runs it through HP's codec and writes the SPL3 stream to the printer with libusb ^[9]. That split exists because CUPS filters cannot invoke the container from their sandbox and the standard USB backend treated the printer as permanently offline; moving both operations outside the sandbox produced a clean test page ^[10].

So the agent did the hard part, and the hard part left a residue. Installation requires Homebrew and adds Colima, Docker and libusb plus a small Linux VM that must stay available, a root LaunchDaemon, and a login item to restart Colima after reboot, with the installer asking for the admin password and downloading HP's Linux driver during setup ^[14]. The repository ships Mehta's glue under MIT and fetches the proprietary binary from HP at install time ^[16]. That is the ownership question in one line: the licence covers the part that is easy to fork, and the runtime depends on a vendor download the project does not control.

The performance profile is honest about the machinery. Conversion and USB delivery take about a second once everything is running, a first print after reboot can wait up to a minute for the VM to start, and a job to a powered-down printer takes 10 to 15 seconds while the fuser heats, according to Mehta ^[15]. Worst-case cold start is therefore roughly sixty times the steady-state cost ^[17].

HP's paperwork is part of why this exists. The 1008a specifications page lists macOS versions through Sonoma as compatible ^[11], the 2023 data sheet mentions AirPrint but restricts wireless and mobile printing to the 1008w in its footnotes, and Mehta found no driverless IPP endpoint on the USB-only model, leaving macOS 26 with no usable built-in path on his machine ^[12].

Watch the test matrix and the fetch step. The project has only been exercised on Apple Silicon Macs running macOS 26, on "a" models and "w" models over USB, with broader compatibility unestablished ^[13] - and every future macOS release, Colima change, or move of HP's Linux driver download lands on a maintainer, not on a vendor support queue ^[14][16].