Linux Firmware Repository Adds AGENTS.md Guidance for AI Coding Agents

The repository that quietly underpins much of Linux hardware support has started writing rules for a new class of contributor. On June 10, 2026, maintainers merged AGENTS.md documentation into linux-firmware.git, the de facto home for the binary blobs that mainline kernel drivers load at runtime. The change does not add a single firmware file. It adds a set of instructions written for software agents rather than people.

That distinction matters because of what linux-firmware.git actually holds. This is the repository that ships microcode updates for x86 processors, the radio firmware for Wi-Fi and Bluetooth controllers, GPU initialization blobs for AMD and Intel graphics, and the device firmware for a long list of network, storage, and sensor components. When a driver in the mainline kernel needs a closed binary to bring hardware up, this is where distributions pull it from. A typical desktop or laptop boot pulls several megabytes of these files, and a modern AMD GPU alone can require firmware payloads measured in the tens of megabytes across its various engines.

What the documentation changes

The merged material adds an AGENTS.md file plus supporting preparations so that coding agents such as Claude Code, OpenAI's Codex, and others can follow established repository practice when adding or updating firmware files. The documentation codifies what the maintainers describe as the golden rules for the repository: how files are placed, how the WHENCE manifest that maps firmware filenames to source and license is maintained, and how each blob must carry its own license file. None of these conventions are new. What is new is that they have been written down in a form an automated agent can read and act on directly.

The self-referential detail is hard to miss. The AI agent documentation was co-authored by Anthropic's Claude Opus 4.8, the model now writing the rules that future models will follow when they touch the tree. The maintainers also endorse a specific provenance practice for these contributions. Agent-assisted commits are expected to carry a co-developed-by or assisted-by Git trailer, which keeps the human-versus-machine authorship visible in the commit history rather than burying it.

Why provenance is the hard part

Firmware is an unusual corner of open source. Most of the files in linux-firmware.git are not open source at all in the conventional sense. They are redistributable binaries shipped under per-vendor licenses, which is exactly why every file carries its own LICENSE and why the WHENCE file exists to track the mapping. The repository's value is not the code inside the blobs, which is opaque, but the legal clarity around redistribution.

That is where the new documentation stops short. It governs how agents should add and update existing vendor-supplied firmware, the routine maintenance that makes up the bulk of repository activity. It does not address the harder scenario: an AI agent modifying or generating firmware binaries as part of reverse engineering or enhancement work. The provenance and licensing status of a machine-altered blob has no clean answer under the current rules, which assume every binary traces back to a vendor with a known license. A firmware file that an agent partially regenerated or patched sits outside that model, and the documentation leaves that gap open beyond pointing at the respective LICENSE.

{{IMAGE:2}}

The broader pattern

The AGENTS.md convention is spreading across infrastructure projects as a vendor-neutral way to give coding agents project-specific instructions, similar in spirit to how a README targets humans or a CONTRIBUTING file targets new developers. Seeing it land in linux-firmware.git is notable less for the technical scope of the change and more for where it landed. This is plumbing that sits below nearly every Linux deployment, from data center fleets to embedded devices, and the maintainers are treating automated contribution as something to plan for rather than fence off.

For an industry already routing more of its routine maintenance through coding agents, the firmware tree is a useful test case. The work is repetitive and rule-bound, which suits automation, but the licensing constraints are strict and the blast radius of a mistake is large. A bad firmware update does not throw a compiler error. It can leave hardware that fails to initialize on millions of machines once distributions pick it up. Writing the rules down for agents, and tagging their work so it stays auditable, is a reasonable first move. The unanswered licensing questions around generated binaries are the part worth watching as the practice matures.