Providers

ADHDev uses a provider system to support IDEs, CLI tools, extensions, and ACP adapters 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
acp	Agent Client Protocol agents	32 built-in adapters

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

Machine Activation For CLI And ACP Providers

For machine-runtime providers (cli and acp), inventory is not the same as launchability on a specific machine. ADHDev now treats these providers as machine-scoped opt-in entries:

1. Open the machine's Providers tab.
2. Enable the provider for that machine.
3. Run Detect so ADHDev verifies the configured executable on that machine.
4. Launch it from the dashboard or CLI once detection succeeds.

The provider card shows the current machine status (Disabled, Enabled, not checked, Not detected, or Detected) plus the latest detection and verification details. This keeps a provider that merely exists in the catalog from appearing as a usable runtime until the local executable has actually been checked.

Custom executable path and args are machine-local provider settings. Use them when a tool is installed outside the default PATH or needs a wrapper command.

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 and hermes-cli have 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/ACP 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.