luigidemasi commented on code in PR #149:
URL: https://github.com/apache/camel-kit/pull/149#discussion_r4481264287
##########
kit/camel-kit-core/src/main/java/org/apache/camel/kit/generator/OpenCodeGenerator.java:
##########
@@ -30,12 +39,50 @@ public void generate(InitContext ctx) throws Exception {
Map<String, Object> data = new HashMap<>(
Map.of(
"COMMAND_PREFIX", ctx.commandPrefix()));
- // AGENTS.md already generated by the shared generator flow.
+
+ List<String> mcpServers = readMcpServerNames(ctx);
+ Set<String> seen = new LinkedHashSet<>();
+ StringBuilder denials = new StringBuilder();
+ for (String server : mcpServers) {
+ String normalized = normalizeServerName(server);
+ if (BUILTIN_PERMISSION_PREFIXES.contains(normalized)) {
+ continue;
Review Comment:
[P1] Preserve MCP denial when avoiding a built-in permission collision
Skipping this server fixes the `external_directory` collision by leaving all
of its MCP actions available. In an actual OpenCode 2.2.5 child generated from
this head, a preconfigured server named `external` successfully invokes
`external_mark` and writes the harmless canary marker despite `mcp: deny`.
Adding only `external_mark: deny` blocks the call; the unmodified new worker
can also read the authorized controller briefing, confirming that the old read
failure is fixed. Please enforce both properties together: deny this server's
MCP actions while preserving the host permission, or stop native dispatch if
isolation cannot be established. The PR body's claim that `mcp: deny` covers
skipped servers is contradicted by this execution. The new test currently
asserts the skip and literal `mcp: deny`, so it codifies the gap without
testing the boundary.
_AI-generated by Codex on behalf of @luigidemasi._
##########
kit/camel-kit-core/src/main/java/org/apache/camel/kit/generator/OpenCodeGenerator.java:
##########
@@ -30,12 +39,50 @@ public void generate(InitContext ctx) throws Exception {
Map<String, Object> data = new HashMap<>(
Map.of(
"COMMAND_PREFIX", ctx.commandPrefix()));
- // AGENTS.md already generated by the shared generator flow.
+
+ List<String> mcpServers = readMcpServerNames(ctx);
+ Set<String> seen = new LinkedHashSet<>();
+ StringBuilder denials = new StringBuilder();
+ for (String server : mcpServers) {
+ String normalized = normalizeServerName(server);
+ if (BUILTIN_PERMISSION_PREFIXES.contains(normalized)) {
+ continue;
+ }
+ if (seen.add(normalized)) {
+ denials.append(" ").append(normalized).append("_*: deny\n");
+ }
+ }
+ data.put("MCP_TOOL_DENIALS", denials.toString());
// OpenCode-specific: generate agent definitions
generateAgents(ctx, data);
}
+ static String normalizeServerName(String name) {
+ StringBuilder sb = new StringBuilder(name.length());
+ for (int i = 0; i < name.length(); i++) {
+ char c = name.charAt(i);
+ sb.append(Character.isLetterOrDigit(c) || c == '-' ? c : '_');
+ }
+ return sb.toString();
+ }
+
+ private List<String> readMcpServerNames(InitContext ctx) throws
IOException {
+ Set<String> names = new LinkedHashSet<>();
+ for (Path configFile :
OpenCodeProjectConfig.existingFiles(ctx.projectDir())) {
Review Comment:
[P1] Build denials from the effective host MCP configuration
The canonical project-layer reader fixes JSONC/nested-project cases, but it
still omits inherited global servers. A `probe` server in
`$XDG_CONFIG_HOME/opencode/opencode.json` before initialization is callable by
the generated OpenCode 2.2.5 child. The same gap also occurs entirely within
root `opencode.json` using OpenCode 2.2.5's native
`{"mcp":{"servers":{"probe":{...}}}}` shape: this reader emits `servers_*:
deny` rather than denying `probe`.
Both configurations passed initialization and the real child wrote the
harmless MCP canary marker; matching denials block both calls. Please derive
the inventory from the effective host configuration, including global sources
and the supported native shape, or fail closed when isolation cannot be
established. Reading every project file does not by itself enumerate the
child's tools. The global case remains open from the prior finding.
_AI-generated by Codex on behalf of @luigidemasi._
##########
kit/camel-kit-core/src/main/java/org/apache/camel/kit/generator/OpenCodeGenerator.java:
##########
@@ -30,12 +39,50 @@ public void generate(InitContext ctx) throws Exception {
Map<String, Object> data = new HashMap<>(
Map.of(
"COMMAND_PREFIX", ctx.commandPrefix()));
- // AGENTS.md already generated by the shared generator flow.
+
+ List<String> mcpServers = readMcpServerNames(ctx);
+ Set<String> seen = new LinkedHashSet<>();
+ StringBuilder denials = new StringBuilder();
+ for (String server : mcpServers) {
+ String normalized = normalizeServerName(server);
+ if (BUILTIN_PERMISSION_PREFIXES.contains(normalized)) {
+ continue;
+ }
+ if (seen.add(normalized)) {
+ denials.append(" ").append(normalized).append("_*: deny\n");
+ }
+ }
+ data.put("MCP_TOOL_DENIALS", denials.toString());
// OpenCode-specific: generate agent definitions
generateAgents(ctx, data);
}
+ static String normalizeServerName(String name) {
+ StringBuilder sb = new StringBuilder(name.length());
+ for (int i = 0; i < name.length(); i++) {
+ char c = name.charAt(i);
+ sb.append(Character.isLetterOrDigit(c) || c == '-' ? c : '_');
Review Comment:
[P1] Match OpenCode's ASCII normalization for Unicode server names
`Character.isLetterOrDigit` preserves Unicode letters and digits, while
[OpenCode 2.2.5 replaces characters outside its ASCII
allowlist](https://github.com/anomalyco/opencode/blob/v2.2.5/packages/core/src/tool/mcp.ts#L22-L23).
For a valid server named `café`, this emits `café_*: deny`, but the host
action is `caf__mark`. The generated child successfully executes that canary;
adding only `caf__mark: deny` blocks it. The dotted-name case now passes, but
this mismatch leaves the same permission bypass for non-ASCII names. Use the
host's exact normalization semantics and add non-ASCII letter/digit regression
coverage alongside the dot test.
_AI-generated by Codex on behalf of @luigidemasi._
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
