Feature: disable built-in adapters + project-level CLI isolation
- Dominant language
- JavaScript
- Stars
- 29.3k
- Forks
- 2.9k
- Avg merge
- 15h 36m
- Merged PRs (30d)
- 70
Description
## Problem
Currently opencli loads all built-in adapters unconditionally. There is no way to suppress them, which causes two practical issues:
### 1. Built-in adapters pollute the agent tool list
When using opencli as an AI agent tool (e.g. via the `smart-search` skill in Claude Code), **all 140+ built-in adapters are exposed to the model at once**. This bloats the tool listing, increases token usage, and makes it harder for the agent to pick the right tool. There is no mechanism to disable or hide specific sites.
**Request:** Add a config option to disable built-in adapters, e.g. in `~/.opencli/config.json`:
```json
{
"disableBuiltins": true,
"disabledSites": ["1688", "amazon", "bloomberg"]
}
```
Or an env var: `OPENCLI_DISABLE_BUILTINS=1`
---
### 2. No project-level CLI isolation
The current discovery order is fixed:
1. `BUILTIN_CLIS` (npm package)
2. `~/.opencli/clis/` (user-level)
3. `~/.opencli/plugins/` (user-level)
There is **no project-local discovery**. When working in a monorepo or a project that defines its own domain-specific tools, there is no way to:
- Scope a set of CLIs to a specific project directory
- Have different projects expose different tool sets to the agent
- Check project-local tools into version control alongside the code
**Request:** Add a project-level discovery step, loading from the current working directory:
```
./.opencli/clis/ ← project-local adapters
./.opencli/plugins/ ← project-local plugins
```
Combined with `disableBuiltins`, this would allow a project to define exactly the tools it needs and expose only those to the agent — clean, isolated, version-controlled.
---
## Use case
A project that communicates with internal APIs wants to expose 3 custom tools to an AI agent, without the agent seeing 140+ unrelated built-in adapters. Today this is impossible without patching the npm package directly.
## Version
`@jackwener/opencli` v1.7.14
Contributor guide
Research direction
Start by tracing the existing discovery order from BUILTIN_CLIS through ~/.opencli/clis/ and ~/.opencli/plugins/. Review how ~/.opencli/config.json or OPENCLI_DISABLE_BUILTINS could control built-in and site loading, then examine discovery from the current working directory. Done means project-local adapters and plugins can be isolated while the requested built-ins or sites are disabled.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- cli, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100