jackwener / jackwener/OpenCLI

Feature: disable built-in adapters + project-level CLI isolation

Open
#1,423 1 comment 1 reaction 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.