luigidemasi commented on code in PR #149:
URL: https://github.com/apache/camel-kit/pull/149#discussion_r4437628037
##########
kit/camel-kit-core/src/main/resources/templates/opencode/agents/camel-ship-worker.md:
##########
@@ -0,0 +1,18 @@
+---
+name: camel-ship-worker
+description: Read-only Camel Ship stage worker dispatched by the parent
OpenCode session.
+mode: subagent
+permission:
+ edit: deny
+ bash: deny
+ task: deny
Review Comment:
**P1 — Enforce the worker’s no-MCP boundary in its effective permissions.**
These rules deny built-in edit, bash, and task, but leave inherited MCP
tools available. Omitting an MCP declaration in this file does not remove
servers configured at project/global scope. Fresh Camel-Kit configuration
enables managed MCP servers with `ask`; unrelated configured servers can remain
allowed by default.
I reproduced this with OpenCode 1.18.30, freshly generated assets, a local
deterministic model endpoint, and a harmless local MCP fixture: an actual
`build -> task(subagent_type="camel-ship-worker")` child received the MCP tool
and invoked it, writing a fixed marker under `/tmp`. With a temporary
deny-by-default policy permitting read/glob/grep, the same child received only
those three tools and no marker was written. No external model or production
MCP tool was used.
Please deny tools by default and allow only the required reading/search
operations, preserving existing path and sensitive-file restrictions. Add a
regression with an unrelated configured MCP server and check effective
permissions. `assertFalse(worker.contains("mcp"))` does not verify this
boundary. Align the no-MCP claims in the documentation and PR description with
the enforced behavior.
This is a violation of the worker’s tool restrictions that can bypass Ship’s
controlled artifact path through enabled MCP capabilities; it is not
demonstrated OS privilege escalation. See [OpenCode MCP
availability](https://opencode.ai/docs/mcp-servers/) and [permission
defaults](https://opencode.ai/docs/permissions/).
_AI-generated by Codex on behalf of @luigidemasi._
##########
kit/camel-kit-core/src/test/java/org/apache/camel/kit/ship/controller/OpenCodeNativeWorkerTest.java:
##########
@@ -0,0 +1,15 @@
+package org.apache.camel.kit.ship.controller;
+
+import org.apache.camel.kit.ship.controller.ShipRun.ExecutionMode;
+
+/**
+ * Validates the shared controller contract for OpenCode native Ship.
Generated assets were verified via a local
+ * OpenCode workspace probe; live child execution acceptance is tracked in #99.
+ */
+class OpenCodeNativeWorkerTest extends ShipNativeWorkerTest {
Review Comment:
**P2 — Supply the full native Ship acceptance required by #99.**
This class selects an execution mode for the shared controller fixtures.
Those fixtures fabricate result envelopes and use deterministic test evidence;
they do not complete Ship through the generated `/camel-ship` entry point on
OpenCode. The new documentation explicitly records live acceptance as pending.
Issue #99 requires a real native workflow with independently verified
artifacts and deterministic validation, plus oversight, interruption/resume,
abort/timeout, repeated submissions, stale/conflicting result rejection, and
workspace/tool restrictions. Please provide that host-backed acceptance
evidence before treating this integration as complete, or obtain an explicit
maintainer-approved scope change that keeps the remaining acceptance work open
and adjusts support claims.
The real-child permission probe described in the other finding verifies a
specific tool boundary. It does not satisfy full Ship workflow acceptance.
_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]
