Claude Code can run on Linux, but it is a coding agent—not a hardware driver. In work on Linux support for a Plustek OpticFilm 8200i scanner, Red Hat engineering director Christian Schaller used the scanner’s behavior with its Windows driver as a reference while developing a Linux implementation. The New Stack reported the project and its results on October 17, 2026; Schaller later released hw-harness, a generalized tool for comparing device behavior across Windows and Linux workflows. The New Stack’s account distinguishes that release from the project-specific tools used for the scanner and a separate camera investigation.
Anthropic supports Claude Code installation on Linux. Its native installer places the executable at ~/.local/bin/claude—the coding tool’s path, not a driver location, according to Anthropic’s setup documentation and user FAQ. A particular device still needs Linux support for its hardware.
How Windows behavior helped with the scanner
The reported compatibility problem involved newer Plustek OpticFilm 8200i units with a Genesys GL128 chipset. SANE, the Linux scanning software, already supported the older Genesys GL845. Schaller said earlier attempts with Claude Code had stalled when the agent lacked a working driver for comparison; he later used Windows-driver behavior as a reference for the Linux implementation, as The New Stack reported.
Schaller’s implementation reportedly supports color and grayscale scanning from 300 to 7,200 dpi, infrared dust removal, and exposure adjustments for dense negatives. In September 2026, support for the newer scanner reportedly landed in SANE through work by another developer. Schaller said he would switch to that upstream version when it had the features he wanted, while keeping his implementation as a proof of concept.
What the released hw-harness does
The public hw-harness project generalizes a comparison workflow; it was not the exact tooling Schaller used for the scanner and camera projects. The New Stack reported that the harness runs a Windows driver in a KVM virtual machine, with the physical device passed through to the virtual machine. Claude controls the Windows session while usbmon captures USB traffic on the Linux host. The device is then switched back to Linux for a second run, so developers can compare the two traces.
The project’s tools divide up the work: winctl controls the Windows virtual machine, usbcap captures traffic, hostdev switches the device between host and guest, and hwdbg supports Linux-side debugging. PowerShell scripts collect device descriptors, registry entries, ACPI tables, and INF files. The New Stack reported that the released harness had not been tested across a broad range of hardware.
What the scanner timing says
In a single-frame, full-resolution comparison reported by The New Stack, Schaller’s implementation scanned in 34.6 seconds; the upstream version took 54.4 seconds. Both resolved the same detail at 3,600 dpi.
| Implementation | Full-resolution scan time |
| Schaller’s implementation | 34.6 seconds |
| Upstream version | 54.4 seconds |
Those figures describe one reported comparison, not typical scan speeds. They show the result of that run; the shared 3,600 dpi detail resolution gives the timing a specific quality context.
The separate ThinkPad camera investigation
Schaller also investigated the camera system in the Lenovo ThinkPad X1 Carbon Gen 14 Aura Edition, which uses a Sony IMX471 sensor and Intel IPU7 imaging system, according to The New Stack. The work drew on Windows configuration files, registry entries, ACPI tables, device properties, and a USB webcam reference.
The New Stack reported that Schaller’s low-light frame-brightness value rose from 31.1 before changes to 90.9 afterward. The blue channel remained about 17% below the USB webcam reference. As of The New Stack’s October 17, 2026 report, neither the Linux-kernel patch set nor the libcamera patch set had been merged.
Why developer experience and hardware checks still matter
A separate example comes from Dmitry Brant, who described using Claude Code to modernize the legacy ftape Linux tape driver. In his first-person account, Brant wrote that the work involved several iterations and manual fixes, drawing on his existing C and kernel-module experience. He tested the resulting module with actual tape drives.
