prod-opencode-instance-inspection

Inspect running production Birdhouse OpenCode instances by mapping workspaces to directories and querying per-directory tool and config state.

36|5|Updated Feb 27, 2026
One-click install
npx skills add https://github.com/Birdhouse-Labs/birdhouse --skill prod-opencode-instance-inspection-birdhouse-labs
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: prod-opencode-instance-inspection
Source: https://github.com/Birdhouse-Labs/birdhouse/tree/main/.agents/skills/internal/birdhouse-development/prod-opencode-instance-inspection
Command: npx skills add https://github.com/Birdhouse-Labs/birdhouse --skill prod-opencode-instance-inspection-birdhouse-labs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When debugging production Birdhouse workspaces, querying a running OpenCode instance without specifying the workspace directory returns config and tool data for the wrong directory, producing false positives. This Skill provides a correct, step-by-step procedure to map workspaces to their OpenCode processes and query per-directory state accurately. ## Core Features & Use Cases - Workspace Discovery: Query the Birdhouse SQLite database to list active workspaces with their directories, OpenCode ports, and pids. - Health Verification: Confirm each OpenCode process belongs to the expected workspace via the /global/health endpoint and its birdhouseWorkspaceId field. - Directory-Scoped Queries: Retrieve tools, resolved config, providers, and model-specific tool definitions using URL-encoded directory query parameters. - Use Case: A developer notices a production workspace exposes unexpected plugin tools. Using this Skill, they query /config?directory=... for the exact workspace path and discover a local .opencode/opencode.json in the repo tree is injecting extra plugins. ## Quick Start Ask the agent to inspect the running production OpenCode instances and verify which tools and config each workspace directory is actually exposing.

Frequently Asked Questions about prod-opencode-instance-inspection

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I inspect running OpenCode instances in production Birdhouse?▼

Query the Birdhouse SQLite database at ~/Library/Application Support/Birdhouse/data.db to get workspace ids, directories, OpenCode ports, and pids. Then match those against running processes and query each instance's health and config endpoints.

Why does the OpenCode tools endpoint show unexpected tools?▼

The most common cause is omitting the directory query parameter, which makes OpenCode resolve config from the server's current working directory instead of the workspace. Always pass the URL-encoded workspace directory to /experimental/tool/ids and /config.

How do I verify which workspace an OpenCode process belongs to?▼

Call the /global/health endpoint on the instance's port and check the birdhouseWorkspaceId field in the response. This confirms workspace ownership, though it does not determine which directory resolves config for subsequent requests.

Can a local .opencode/opencode.json affect production workspace config?▼

Yes. If a workspace sits inside a directory tree containing .opencode/opencode.json, directory crawling can discover it and inject extra plugins. Compare config responses for workspaces inside and outside that tree to detect this.

How do I check which tools an LLM model can actually use in OpenCode?▼

Query /experimental/tool with provider, model, and directory parameters to get model-filtered tool definitions. Get valid provider and model pairs first from the /config/providers endpoint for the same directory.