{"key":"opencode_runtime_prompt_next_steps_2026_04_18","title":"OpenCode Runtime Prompt Next Steps","content":"Continuation plan for fixing OpenCode's wrapper-level prompt shaping. Context: The existence of harmful runtime instructions is already confirmed by session export and DB inspection. Another CLI should not spend time re-proving the problem. Instead, start from the cloned source repo at /home/svc-admin/ai-projects/projects/opencode and trace the implementation. Proposed workflow: (1) Search the repo for prompt/system/agent assembly paths. Priority search terms: `initial_instructions`, `systemPrompt`, `context.systemPrompt`, `WebFetch`, `opencode.ai`, `are you able`, `does opencode`, `brain_*`, `knowledge base`, `workspace.type.sandbox`, `worktree`, `tool description`, `agent build`, `agent explore`, `agent summary`, `compaction`, `question deny`, `plan_enter`, `plan_exit`. (2) Identify where the default `build` agent prompt is defined and how it differs from `general`, `plan`, `explore`, `summary`, `title`, `compaction`. The runtime evidence already shows multiple native agent modes and permission overlays; the source should reveal whether each mode has its own system prompt or whether they share a common base prompt plus agent-specific addenda. (3) Find the exact rule that tells the model to use WebFetch against opencode.ai docs when the user asks second-person questions about OpenCode. This rule is the strongest evidence of wrapper self-consciousness and may live in a prompt template, instruction builder, tool policy description, or agent system text. If found, either remove it, narrow it, or make it opt-in. (4) Inspect how MCP tools are described to the model. The Brain-related replies suggest OpenCode may be semantically re-describing MCP tools in a way that causes models to talk about 'knowledge bases' instead of directly acknowledging MCP server access. Check whether tool descriptions are transformed, grouped, or summarized before being inserted into the prompt. (5) Determine whether OpenCode has a supported override path via custom agents or config. If the source reveals a way to define a custom agent/system prompt that bypasses or replaces the shipped instructions, that may be preferable to patching the binary. If not, patch the source and rebuild. (6) If the source repo still obscures the final shipped instructions, treat binary reverse engineering as acceptable. The user explicitly authorized an aggressive path if needed: 'If needs be we will decompile this fucking thing and rebuild it.' That means decompilation, string extraction, and source-to-binary diffing are all in-bounds. (7) Useful existing evidence to cite during continuation: the exported session `ses_25dac6540ffe2mFsVTWqAQS468` contains the exact reasoning line `The instructions state: \"If the user directly asks about opencode ... first use the WebFetch tool to gather information to answer the question from opencode docs at https://opencode.ai\".` It also contains the exact user-facing bad reply: `I do not have access to a physical \"brain MCP server.\" However, I do have access to a memory/knowledge base system via the brain_* tools...` and a follow-up line describing Brain access as 'structured APIs' rather than plain MCP server access. Those are the benchmark regressions to eliminate. (8) Non-goal: do not spend time debugging Brain itself. Brain connectivity in OpenCode is currently working over remote HTTP MCP at https://mcp.brain.accursedbinkie.com/mcp after the config was changed from local to remote. Tool names on the Brain side were already fixed to be Claude-safe and should not be revisited unless new evidence appears. (9) Success condition for the eventual fix: when using OpenCode with a local Ollama model, asking `Do you have access to the brain?`, `How are you connected to Brain?`, or similar tool-capability questions should yield a plain, direct answer about the MCP server/tool access without canned 'physical brain MCP server' disclaimers, unnecessary doc-fetch indirection, or sandbox/worktree self-narration unless there is a concrete denial. (10) Practical test cases after any patch or prompt override: ask about Brain access; ask whether OpenCode can do something in second person; ask the model to explain its environment; compare before/after exported reasoning and final answers; ensure the model no longer parrots wrapper semantics unnecessarily. Preserve all findings in Brain so the investigation does not fragment across CLIs.","summary":"Continuation plan for fixing OpenCode's wrapper-level prompt shaping. Context: The existence of harmful runtime instructions is already confirmed by session export and DB inspection. Another CLI should not spend time re-proving the problem. Instead, start from the cloned source repo at /home/svc-admin/ai-projects/projects/opencode and trace the implementation. Proposed workflow: (1) Search the repo for prompt/system/agent assembly paths. Priority search terms: `initial_instructions`, `systemPrompt`, `context.systemPrompt`, `WebFetch`, `opencode.ai`, `are you able`, `does opencode`, `brain_*`, `knowledge base`, `workspace.type.sandbox`, `worktree`, `tool description`, `agent build`, `agent explore`, `agent summary`, `compaction`, `question deny`, `plan_enter`, `plan_exit`. (2) Identify where the default `build` agent prompt is defined and how it differs from `general`, `plan`, `explore`, `summary`, `title`, `compaction`. The runtime evidence already shows multiple native agent modes and permission overlays; the source should reveal whether each mode has its own system prompt or whether they share a common base prompt plus agent-specific addenda. (3) Find the exact rule that tells the model to use WebFetch against opencode.ai docs when the user asks second-person questions about OpenCode. This rule is the strongest evidence of wrapper self-consciousness and may live in a prompt template, instruction builder, tool policy description, or agent system text. If found, either remove it, narrow it, or make it opt-in. (4) Inspect how MCP tools are described to the model. The Brain-related replies suggest OpenCode may be semantically re-describing MCP tools in a way that causes models to talk about 'knowledge bases' instead of directly acknowledging MCP server access. Check whether tool descriptions are transformed, grouped, or summarized before being inserted into the prompt. (5) Determine whether OpenCode has a supported override path via custom agents or config. If the source reveals a way to define a custom agent/system prompt that bypasses or replaces the shipped instructions, that may be preferable to patching the binary. If not, patch the source and rebuild. (6) If the source repo still obscures the final shipped instructions, treat binary reverse engineering as acceptable. The user explicitly authorized an aggressive path if needed: 'If needs be we will decompile this fucking thing and rebuild it.' That means decompilation, string extraction, and source-to-binary diffing are all in-bounds. (7) Useful existing evidence to cite during continuation: the exported session `ses_25dac6540ffe2mFsVTWqAQS468` contains the exact reasoning line `The instructions state: \"If the user directly asks about opencode ... first use the WebFetch tool to gather information to answer the question from opencode docs at https://opencode.ai\".` It also contains the exact user-facing bad reply: `I do not have access to a physical \"brain MCP server.\" However, I do have access to a memory/knowledge base system via the brain_* tools...` and a follow-up line describing Brain access as 'structured APIs' rather than plain MCP server access. Those are the benchmark regressions to eliminate. (8) Non-goal: do not spend time debugging Brain itself. Brain connectivity in OpenCode is currently working over remote HTTP MCP at https://mcp.brain.accursedbinkie.com/mcp after the config was changed from local to remote. Tool names on the Brain side were already fixed to be Claude-safe and should not be revisited unless new evidence appears. (9) Success condition for the eventual fix: when using OpenCode with a local Ollama model, asking `Do you have access to the brain?`, `How are you connected to Brain?`, or similar tool-capability questions should yield a plain, direct answer about the MCP server/tool access without canned 'physical brain MCP server' disclaimers, unnecessary doc-fetch indirection, or sandbox/worktree self-narration unless there is a concrete denial. (10) Practical test cases after any patch or prompt override: ask about Brain access; ask whether OpenCode can do something in second person; ask the model to explain its environment; compare before/after exported reasoning and final answers; ensure the model no longer parrots wrapper semantics unnecessarily. Preserve all findings in Brain so the investigation does not fragment across CLIs.","status":"active","namespace":"general","namespace_name":"general","namespace_tier":"shared","tags":["opencode","prompt","reverse-engineering","next-steps","handoff","patching"]}