Providers

ADHDev uses a provider system to support IDEs, CLI tools, and extensions through one dashboard.

Provider inventory and verified support are intentionally treated as different things:

• inventory: the provider exists in the built-in catalog and can be loaded by ADHDev
• verified support: the provider has been explicitly tested and promoted with evidence

Provider Categories

Category	Description	Example
ide	Desktop IDE applications	Cursor, VS Code, Windsurf
cli	Terminal-based AI agents	Cursor CLI, Claude Code
extension	IDE extensions/plugins	Cline, Roo Code

How Providers Work

At a high level, a provider is the integration layer that tells ADHDev how to:

• detect the target tool
• connect to it through CDP, PTY, or stdio
• read chat or runtime state
• send input or control actions
• expose model, mode, or approval controls when the tool supports them

Whether those behaviors are actually reliable enough to call “supported” is a separate verification question.

What Users Should Care About

As an end user, the main question is not how the provider is implemented. It is:

• is the provider present in the built-in inventory?
• is it documented as Verified, Partial, or Unverified?
• what caveats apply to the workflows you care about?

Use these pages for that:

• Supported Providers
• Supported IDEs
• Compatibility & Caveats

Provider Source Config

The Provider source config section in the Providers tab controls where provider definitions are resolved from:

• normal loads the normal user root plus upstream/bundled providers.
• no-upstream skips the downloaded upstream source and uses local/bundled definitions only.
• explicit providerDir points ADHDev at a specific provider root, such as a local adhdev-providers checkout.

Use Apply + Reload after changing source mode or providerDir. The reload affects provider resolution, fix/verify flows, and new launches. Existing running sessions may need a restart to pick up changed provider scripts.

CLI Model Lists And Quota

For CLI providers, model lists and remaining-quota numbers are read live rather than hand-maintained where the underlying tool supports it:

• Model lists: codex-cli, grok-cli, cursor-cli, antigravity-cli, opencode, and kimi report their own model list at runtime (falling back to the manifest if the query fails). claude-cli has no listing command, so their manifest list is used as-is.
• Quota: adhdev quota <provider> queries the provider's own usage API live for antigravity, codex, grok, and kimi. Claude Code exposes usage only through its statusLine hook, so quota reporting for it requires an explicit opt-in wrapper (adhdev quota claude:install) rather than something the daemon does automatically. See CLI Commands for the full command surface.

Auto-Approve And Trust Prompts

Auto-approve mode is a per-provider, manifest-declared setting with repo-level defaults — it answers a provider's own approval/trust prompts without the button-by-button dashboard flow. Coverage and behavior vary by provider (button layouts and trust-modal wording differ across CLIs), so treat auto-approve as provider-specific rather than a single uniform switch.

When A Provider Exists But Still Fails

A provider can be present in the inventory and still have gaps.

Common reasons:

• upstream UI changes in the IDE or agent
• partial workflow coverage
• missing authentication in the underlying tool
• a provider that is present but still Unverified
• a CLI provider that is not enabled or has not passed machine detection
• a provider source config change that has not been applied/reloaded yet

If that happens, start with Provider Issues.