Compatibility & Caveats
ADHDev ships a broad built-in provider inventory, but compatibility should still be read conservatively. This page is the quickest way to set expectations before you depend on a specific workflow.
Inventory First, Verification Second
Use this rule of thumb:
- Built-in means the provider exists in the shipped inventory.
- Verified means the provider has been manually tested and promoted.
- Until a provider is promoted, treat it as unverified even if it appears in launchers, docs, or the capabilities page.
Practical Starting Points
If you are evaluating ADHDev for real use, start with providers that already have public Partial evidence rather than just inventory presence.
IDE Workflows
- Cursor
Cursor is currently the clearest public starting point for IDE-style control, Remote View, and session switching.
Extension Workflows
- Codex extension
This is the extension path with the strongest current public evidence. Other extensions may still appear in inventory or launch surfaces, but they should be treated as exploratory until promoted.
CLI Workflows
- Claude Code
- Codex CLI
These run through the hosted PTY/session-host stack and are usually the easiest place to validate remote monitoring and recovery flows.
Known Caveats
IDE support is Electron-first
ADHDev relies on Chrome DevTools Protocol for IDE control. That means Electron-based IDEs are the main target today.
- Electron-first target set today: Cursor, Windsurf, Kiro, PearAI, Antigravity, Trae
- Detection/launch coverage: VS Code, VSCodium
- Not a fit today: non-Electron IDEs such as Zed, IntelliJ, and similar native desktop apps
VS Code family is not the same as Cursor/Windsurf
VS Code and VSCodium can be detected and launched, but they are not the same thing as a native integrated AI IDE. They become much more relevant when you add an extension flow such as Cline, Roo Code, Codex, or Claude Code.
Trae has a real caveat
Trae works for chat and control, but its model and mode controls still rely on generic UI interaction and can fail depending on the app version and layout.
In practice:
- Reading chat works
- Sending messages works
- Remote view works
- Model switching and mode switching should be treated as partial
Some ACP agents depend on upstream experimental flags
A few ACP adapters depend on upstream features that are still marked experimental by their own tools.
- Gemini CLI (ACP) currently starts with
--experimental-acp - Qwen Code (ACP) currently starts with
--experimental-skills
These can still be useful, but they should be treated as experimental rather than default-safe choices.
Authentication is still tool-specific
ADHDev does not replace each tool's own login flow.
- CLI and ACP agents still require their own API keys or login state
- A missing API key can look like a launch failure if you have not authenticated the underlying tool yet
- This is especially important for Gemini, Claude, Codex, and many ACP agents
Push notifications are platform-dependent
Push notifications work best when the dashboard is installed as a PWA.
- iOS requires the PWA install path for web push
- Notification action buttons are not consistently shown across all platforms
- The notification itself may arrive even when action buttons are not available
Windows currently blocks Node.js 24+
ADHDev currently treats Windows + Node.js 24+ as unsupported for normal npm/global CLI install and startup.
- The PowerShell one-line installer now bootstraps a portable Node.js 22 runtime when it detects this combination
- If you plan to use
npm install -g adhdevdirectly on Windows, use Node.js 22.x - This is a temporary safeguard until the Windows PTY/session-host path is stable on newer Node releases
Cloud vs Standalone Expectations
Cloud
Use cloud when you need:
- Access from outside your local network
- Push notifications
- Multi-machine management
- API keys and webhooks
Standalone
Use standalone when you need:
- A local-only setup
- No cloud dependency
- LAN-based monitoring and control
Standalone is great for OSS users and local teams, but cloud-only features such as push notifications and internet-facing remote access are not part of that path.
What Usually Works Best Today
If you want the most representative first impression of the product, these are still the safest starting paths:
- Cursor on desktop, optionally with mobile approvals or Remote View
- Codex extension inside a supported host IDE if you specifically want an extension workflow
- Claude Code or Codex CLI through the dashboard terminal
- One machine with one IDE first, then multi-machine after the basics feel stable
Where To Check Current Status
For the current promoted list and category-by-category status, use Supported Providers. That page is the public reference for what is merely present in inventory versus what has explicit validation behind it.