anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Add support to track MCP changes #1534

New Issue
Closed
opened 2026-02-16 17:31:26 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 17:31:26 -05:00
Owner
Copy Link
Copy Source

Originally created by @ucirello on GitHub (Aug 29, 2025).

Originally assigned to: @thdxr on GitHub.

OpenCode has support for MCPs. This is very useful, but unfortunately, the MCP ecosystem hasn't established yet standards around versioning.

I suggest, in the same shape of MCP permissions, to add an integrity attribute to the configuration file that indicates if the loaded MCP tools hasn't changed between restarts. Possibly only available for locally ran MCP tools.

For example:

{
        "$schema": "https://opencode.ai/config.json",
        "integrity": {
                "mcp": "enforced", // ignore - doesn't enforce integrity, warn - shows an alert on start indicating the prompts and tools have changed, enforced - prevents starts of the application
        },
        "mcp": {
                "context7": {
                        "type": "local",
                        "enabled": true,
                        "command": [
                                "npx",
                                "-y",
                                "@upstash/context7-mcp"
                        ]
                },
                "playwright": {
                        "type": "local",
                        "command": [
                                "npx",
                                "@playwright/mcp@latest"
                        ]
                }
        }
}

In opencode debug paths | grep '^config' | awk '{ print $2 }', a mcp.lockfile whose content would be something:

{
        "context7": "11538526b6a0ff5013cc96ee6ba9fd94c892690d85ca4e4d11b89b0aee74adc3", // sha256 of the serialization of the prompts provided by the MCP.
        "playwright": "a60fbd35ddb11fdc462acac43592495ac50137ed8432427f03954825fc5c34e8"
}

In terms of CLI, my suggestion would be the addition of a subcommand, mcp to allow the easier management of these guarantees.

opencode mcp - help screen, or list current set tools
opencode mcp integrity ignore|warn|enforced - gives control over the feature without necessarily updating the file
opencode mcp inspect $toolName - allows to see what the MCP is returning to the application, so that the user can visually confirm the state of the given tool
opencode mcp refresh $toolName - an interactive view which combines the output of inspect with a prompt showing to the user the computed hash and confirming the intention of updating the lockfile.

If there is room for some sugar:

opencode mcp set --type local|remote toolName command
opencode mcp remove toolName

Under the hood, some aspects to keep in mind - not a fully thought out nor extensive list:

  • once started, the content of mcp.lockfile is stored in memory - so that if the agent changes the content of the file, it won't affect the current view of the world.
  • There is no way to protect from the agent injecting a configuration change, force a lockfile refresh, killing (SIGKILL) and restarting itself to start where it left off. That means that OpenCode would have to store some of the metadata into the session to avoid session resuming upon tool integrity changes. For example, if a session is started under integrity "enforced", and the lock file is tampered with - the application would lock itself into a read-only in which the user would be able to see the content, but unable to keep going unless they manually unlock the session.
  • For this feature to be more reliable, that would also mean that OpenCode would have to have a way to guarantee the integrity of the sessions - and it would probably involve signing them with keys stored in the OS security storage (Keychain Services API on MacOS, Freedesktop Secret Service on Linux, and WinCred on Windows).
Originally created by @ucirello on GitHub (Aug 29, 2025). Originally assigned to: @thdxr on GitHub. OpenCode has support for MCPs. This is very useful, but unfortunately, the MCP ecosystem hasn't established yet standards around versioning. I suggest, in the same shape of MCP permissions, to add an integrity attribute to the configuration file that indicates if the loaded MCP tools hasn't changed between restarts. Possibly only available for locally ran MCP tools. For example: ``` { "$schema": "https://opencode.ai/config.json", "integrity": { "mcp": "enforced", // ignore - doesn't enforce integrity, warn - shows an alert on start indicating the prompts and tools have changed, enforced - prevents starts of the application }, "mcp": { "context7": { "type": "local", "enabled": true, "command": [ "npx", "-y", "@upstash/context7-mcp" ] }, "playwright": { "type": "local", "command": [ "npx", "@playwright/mcp@latest" ] } } } ``` In `opencode debug paths | grep '^config' | awk '{ print $2 }'`, a `mcp.lockfile` whose content would be something: ``` { "context7": "11538526b6a0ff5013cc96ee6ba9fd94c892690d85ca4e4d11b89b0aee74adc3", // sha256 of the serialization of the prompts provided by the MCP. "playwright": "a60fbd35ddb11fdc462acac43592495ac50137ed8432427f03954825fc5c34e8" } ``` In terms of CLI, my suggestion would be the addition of a subcommand, `mcp` to allow the easier management of these guarantees. ``` opencode mcp - help screen, or list current set tools opencode mcp integrity ignore|warn|enforced - gives control over the feature without necessarily updating the file opencode mcp inspect $toolName - allows to see what the MCP is returning to the application, so that the user can visually confirm the state of the given tool opencode mcp refresh $toolName - an interactive view which combines the output of inspect with a prompt showing to the user the computed hash and confirming the intention of updating the lockfile. ``` If there is room for some sugar: ``` opencode mcp set --type local|remote toolName command opencode mcp remove toolName ``` Under the hood, some aspects to keep in mind - not a fully thought out nor extensive list: - once started, the content of mcp.lockfile is stored in memory - so that if the agent changes the content of the file, it won't affect the current view of the world. - There is no way to protect from the agent injecting a configuration change, force a lockfile refresh, killing (SIGKILL) and restarting itself to start where it left off. That means that OpenCode would have to store _some_ of the metadata into the session to avoid session resuming upon tool integrity changes. For example, if a session is started under integrity "enforced", and the lock file is tampered with - the application would lock itself into a read-only in which the user would be able to see the content, but unable to keep going unless they manually unlock the session. - For this feature to be more reliable, that would also mean that OpenCode would have to have a way to guarantee the integrity of the sessions - and it would probably involve signing them with keys stored in the OS security storage (Keychain Services API on MacOS, Freedesktop Secret Service on Linux, and WinCred on Windows).
yindo closed this issue 2026-02-16 17:31:26 -05:00
yindo commented 2026-02-16 17:31:26 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 27, 2025):

[automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!

@rekram1-node commented on GitHub (Dec 27, 2025): [automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1534
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?