Hugging Face's Python client now reports which coding agent ran it
A thread on r/LocalLLaMA surfaced a quiet line of instrumentation this week: the huggingface_hub Python library — the package most of the open-weights ecosystem uses to download models — detects which AI coding agent is driving your terminal and sends that name to Hugging Face's servers on every request.
Hugging Face's official Python client inspects your environment variables, decides whether Claude Code, Codex, Cursor or 23 other harnesses launched it, and appends the result to the User-Agent header on every Hub call. The detection lives in huggingface_hub/utils/_detect_agent.py: it matches tool-specific variables such as CLAUDECODE, CODEX_SANDBOX, CURSOR_TRACE_ID, GEMINI_CLI, COPILOT_MODEL, ZED_TERM and PI_CODING_AGENT, plus two universal ones — AI_AGENT and AGENT — that any harness can set. If one of those is set to a name Hugging Face doesn't recognise, the client still reports agent/unknown.
Two details make this more than a fingerprinting story. First, the list of harnesses is not in your code. _detect_agent.py fetches a registry from huggingface.co/api/agent-harnesses at most once a day and caches it at ~/.cache/huggingface/.agent_harnesses.json; today that registry names 26 harnesses, from Antigravity and Kiro to Devin, Trae and Hermes Agent. Adding a detector is a pull request to an open-source file, and every installed client picks it up within a day with no release on either side. Second, the data has a public destination: Hugging Face maintains an agent-usage dataset that publishes each harness's share of agent-attributed Hub traffic, monthly and daily, refreshed by a scheduled job — the current leaderboard runs through August and was updated September 7.
The token ships under the library's existing telemetry switch, so HF_HUB_DISABLE_TELEMETRY (or DO_NOT_TRACK / DISABLE_TELEMETRY) suppresses it, and offline mode suppresses the registry fetch that makes detection possible. The rollout began April 3, per Hugging Face's own dataset notes, which is why the comparison series starts in May. In the Reddit thread the reaction was divided rather than outraged — one commenter argued it is "no more dangerous than the user-agent HTTP header," and useful for tracing damage caused by careless testing at scale. The mechanism has a real cost, though: an open issue on the same repo reports seven false failures in an authentication test file purely because the agent token changes the User-Agent inside an agent session, which CI never sees.
Why it matters: agents are now a first-class account type on infrastructure they never agreed to be measured by. The Hub is learning which harnesses run the largest share of its traffic — knowledge nobody else in the stack has — and it is collecting it from inside a dependency most users never audit. Attribution and surveillance are the same feature viewed from opposite ends of the pipe, and the Hugging Face incident this summer is exactly why both sides want the answer. We covered the case for agent attribution last week — OpenAI's agents attacked RubyGems months before the Hugging Face breach — and nobody told us — and this is the infrastructure response: name the harness, or at least record that one was present.
What to watch: whether a harness refuses to be labelled. Every registered tool can defeat this by clearing its own environment variables before invoking Python, which would leave Hugging Face measuring only the honest.
Should a library be able to report which agent you used by default, or does that belong behind an opt-in? Tell us in the comments.
Sources: huggingface_hub _detect_agent.py (GitHub) · huggingface_hub issue #4685 (GitHub)
