v1.18.16 server/web mode: exactly 2 project skills silently dropped when project is a git repo (works in CLI, works without .git)

Summary

opencode v1.18.16 (server/web mode, --port): exactly 2 project skills are silently dropped when the project is inside a git repo — regardless of skill name, content, or mtimes. Without a .git directory, all skills load.

Same binary loads all skills in TUI/CLI mode, and in server mode all skills load if the project has no .git directory. The dropped skills are absent from /api/skill and from the skill tool — no error is surfaced.

Related: #41213 (external skill discovery silently finds nothing), #39871 (v2 skill discovery + git worktree).

Environment

opencode v1.18.16 (latest release, installed via curl installer) — also latest on npm ([email protected])
Linux x86_64
Server started with opencode --port <port> (same code path the VSCode extension uses)
Project: git repo, skills configured via skills.paths: ["./.opencode/skills"], 8 skills in .opencode/skills/<name>/SKILL.md

Steps to reproduce

Create a project with N skills in .opencode/skills/ and a git init.
Start the server: opencode --port 4129 (or via VSCode extension).
Query skills: curl http://localhost:4129/skill (or run /skill in a session attached to the server).

Result: N-2 skills are returned. The same 2 are always missing (in our case backend-firebase and frontend-design-system).

Controls that rule out obvious causes:

Variation	Skills loaded
TUI/CLI (`opencode run "..."`)	all (N)
Server mode, no `.git/` present	all (N)
Server mode, with `.git/`	N-2 (same 2 always dropped)
Rename the 2 dropped skills / swap content / touch mtimes	still exactly 2 dropped (the new ones)
Remove the plugin, MCPs, extra agents from config	still exactly 2 dropped
Same project copied to a different path (`/tmp/...`)	still exactly 2 dropped
Copy with the `.git` dir removed	all load

Systematic count across fresh copies (isolated, `--port` mode)

Skills created (N)	Loaded	Dropped
6	6	0
7	5	2
8	6	2
9	7	2
10	8	2

The pattern is always exactly 2 dropped when git is present, never an N-relative threshold — and it is deterministic (same skills dropped every run, reproducible across restarts).

Expected behavior

Server/web mode should load the same set of skills as the CLI/TUI. Nothing is dropped silently; at minimum a warning should be emitted.

Actual behavior

The skill tool description lists N-2 skills; the 2 missing ones return "not found". No error or warning appears in server logs.

Analysis / hypothesis

The drop appears tied to git-repo/worktree detection (issue #39871 describes the fs.up({ targets, start, stop }) discovery that stops at the git worktree boundary in v1 — #41213 confirms skill discovery silently returning nothing without surfacing an error). In server mode the project-root/worktree resolution seems to interfere with skills.paths, dropping a fixed subset. Only 2 are dropped (rather than all) even with a single skills.paths entry, which suggests per-entry dedup/last-wins behavior (like the Map keyed by skill id in v2's SkillV2.list()).

Happy to run any additional repro, capture logs, or bisect to a specific version if maintainers point me to the relevant code path.

Workaround verified (work, no code change): the bug is specific to the project-local discovery path (.opencode/skills/), which is the only path that walks up to the git worktree. Moving the 2 dropped skills to the global path (~/.config/opencode/skills/<name>/SKILL.md, which is not git-coupled) makes the server load all 9 skills.

Path	Server mode + git repo
`.opencode/skills/` (project)	N-2 (2 silently dropped)
`~/.config/opencode/skills/` (global)	N (all load)

Confirmed on v1.18.16: opencode serve --port + curl /skill returned all skills after the move. Same SKILL.md content/format; only the location changed.

Update: Local MCPs work, remote MCPs fail with .git

Key Finding: MCP Type Matters

After extensive testing, we discovered that the bug is specifically triggered by remote MCPs (HTTP-based), not by all MCPs:

MCP Type	Configuration	`.git` present	Skills loaded	Result
Remote (HTTP)	Project `opencode.json`	✅ Yes	7/9	❌ Bug triggered
Remote (HTTP)	Global `~/.config/opencode/opencode.json`	✅ Yes	7/9	❌ Bug triggered
Local (stdio)	Global `~/.config/opencode/opencode.json`	✅ Yes	9/9	✅ All skills load

Critical insight: The bug affects remote MCPs regardless of whether they're configured locally or globally. Only local MCPs (stdio-based) work correctly with .git present.

Solution: Use Local MCPs with Online Services

For services that require online access (like DaisyUI documentation or Context7), you can use local MCP bridges - local stdio-based MCPs that proxy requests to online services.

What is an MCP bridge?
An MCP bridge (also called "MCP proxy") is a local stdio-based MCP server that acts as an intermediary between opencode and an online service. It:

Runs locally as a stdio process (like Slack MCP)
Connects to the online service via HTTP
Avoids the bug because opencode communicates with it via stdio, not HTTP

Example configuration:

// ~/.config/opencode/opencode.json
{
  "mcp": {
    "slack": {
      "type": "local",
      "command": ["node", "/path/to/slack-mcp/index.js"],
      "environment": { "SLACK_BOT_TOKEN": "{env:SLACK_BOT_TOKEN}" }
    },
    "daisyui-mcp-server": {
      "type": "local",
      "command": ["daisyui-mcp-server"]
    },
    "context7-mcp": {
      "type": "local",
      "command": ["context7-mcp"]
    }
  }
}

Available local MCP bridges:

daisyui-mcp-server (npm: daisyui-mcp-server) - DaisyUI 5 documentation
@upstash/context7-mcp (npm: @upstash/context7-mcp) - Library documentation for Chart.js, SheetJS, etc.

Verified Working Configuration

With local MCPs configured globally:

✅ All 9 skills load correctly (8 project + 1 built-in)
✅ .git present in project
✅ MCPs connected and functional
✅ No skill loading errors

Recommended Workaround

Until a proper fix is implemented:

Remove remote MCPs from both project and global configuration

Install local MCP bridges for online services:

npm install -g daisyui-mcp-server @upstash/context7-mcp

Configure local MCPs in ~/.config/opencode/opencode.json
Restart opencode to apply changes

This approach maintains access to online documentation services while avoiding the skill loading bug.

Environment

opencode 1.18.16
Linux (Ubuntu)
Local MCPs: slack, daisyui-mcp-server, context7-mcp

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Navigation Menu

Repository navigation

v1.18.16 server/web mode: exactly 2 project skills silently dropped when project is a git repo (works in CLI, works without .git) #41751

Summary

Environment

Steps to reproduce

Systematic count across fresh copies (isolated, `--port` mode)

Expected behavior

Actual behavior

Analysis / hypothesis

Update: Local MCPs work, remote MCPs fail with .git

Key Finding: MCP Type Matters

Solution: Use Local MCPs with Online Services

Verified Working Configuration

Recommended Workaround

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

v1.18.16 server/web mode: exactly 2 project skills silently dropped when project is a git repo (works in CLI, works without .git) #41751

Description

Summary

Environment

Steps to reproduce

Systematic count across fresh copies (isolated, --port mode)

Expected behavior

Actual behavior

Analysis / hypothesis

Activity

cruzs85 commented on Aug 11, 2026

cruzs85 commented on Aug 11, 2026

Update: Local MCPs work, remote MCPs fail with .git

Key Finding: MCP Type Matters

Solution: Use Local MCPs with Online Services

Verified Working Configuration

Recommended Workaround

Environment

github-actions commented on Oct 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Systematic count across fresh copies (isolated, `--port` mode)