Summary
- The llm-tools-datasette plugin stopped functioning after LLM 0.33 switched its HTTP client from httpx to httpx2.
- The plugin had been relying on httpx as an implicit transitive dependency rather than declaring it explicitly.
- The breakage was silent — the plugin existed but no longer worked as expected without an obvious error pointing to the root cause.
- Version 0.1.1 of llm-tools-datasette resolves the issue by correcting the dependency declaration.
- The incident illustrates a broader risk in plugin-based AI tooling ecosystems: upstream refactoring can quietly invalidate downstream components.
What Happened
Simon Willison, the developer behind both the LLM command-line tool and the Datasette data exploration platform, released llm-tools-datasette 0.1.1 this week to address a breakage introduced indirectly by an upgrade in the core LLM framework. When LLM 0.33 migrated its HTTP client from httpx to httpx2, plugins that had been using httpx without explicitly listing it as a dependency stopped working. The llm-tools-datasette plugin was among those affected.
The Mechanism: Implicit Transitive Dependencies
The issue is a classic dependency management problem. The plugin had access to httpx not because it declared a requirement for it, but because LLM itself depended on httpx, and that library was therefore present in the environment. When LLM moved to httpx2, the original httpx was no longer guaranteed to be installed. Plugins that had assumed its presence — without formally requiring it — broke without any obvious signal pointing to the underlying cause.
A Common Risk in Ecosystem Tooling
This pattern is not unique to the LLM ecosystem. It appears regularly across plugin architectures in Python, Node.js, and elsewhere: a library is available at runtime because something else pulled it in, developers build against it without formalising the dependency, and a later refactor upstream removes the implicit supply. The result is breakage that can be difficult to diagnose because nothing explicitly declared a dependency on the missing library.
Relevance for Security Tooling
From a security operations perspective, the significance here is not about a vulnerability in the traditional sense. No exploit, no data exposure, and no threat actor is involved. However, the pattern is relevant to any organisation running AI-adjacent tooling — including LLM-powered data querying tools like those built on Datasette — as part of a security or data analysis workflow. A plugin silently ceasing to function after a routine framework upgrade is operationally disruptive, and if the tooling is part of an automated pipeline, the failure may not be immediately visible.
The Fix
Willison acknowledged the oversight directly, noting that when he switched LLM over to httpx2 he forgot it would break plugins that used httpx without directly depending on it. The fix in version 0.1.1 corrects the dependency declaration so that the plugin explicitly requires what it uses, rather than relying on whatever the parent framework happens to bring along.
Broader Considerations for Plugin Governance
Organisations adopting AI framework plugins — whether for LLM orchestration, data access, or security tooling integration — should be aware that the plugin ecosystem for these tools is maturing rapidly but is not yet subject to the same level of dependency hygiene enforced in more established software supply chains. Third-party plugins in particular may carry undeclared transitive dependencies. Without explicit dependency pinning and regular compatibility testing, upgrades to core frameworks can cascade unpredictably into downstream tools.
Why it matters
Security teams increasingly integrate LLM-based tools into data workflows and operational pipelines. When a core framework upgrade silently breaks a plugin due to an undeclared transitive dependency, the failure may go unnoticed in automated or background processes. This incident is a practical prompt for CISOs to review whether AI-adjacent tooling in their environment is subject to explicit dependency management and regression testing — and whether upgrade paths for core frameworks are validated against the full plugin surface before deployment.
What to do now
- Update llm-tools-datasette to version 0.1.1 if it is in use in your environment.
- Review other LLM plugins in your environment that may have been affected by the LLM 0.33 upgrade to httpx2, checking for similar implicit dependency assumptions.
- Establish a practice of testing plugin compatibility after any core framework version upgrade before deploying to production or automated pipelines.
- Where possible, prefer plugins that explicitly declare all their dependencies rather than relying on transitive availability from the parent framework.
