PR #396 #1172
cameroncookecodeql
on: dynamic
Matrix: analyze
Annotations
4 warnings
|
Snapshot availability probe shells out to real xcrun and Xcode:
src/snapshot-tests/xcode-ide-availability.ts#L1
The new helper invokes real `xcrun --find mcpbridge` and `pgrep -x Xcode` via `execSync` to gate snapshot tests. This couples the test suite to the host environment (real xcrun, a running Xcode app) instead of injected command/filesystem dependencies, violating the guardrail that unit/snapshot tests must not call real `xcrun`, devices, or simulators. Tests will behave differently across machines and CI, and they introduce hidden dependence on the developer's Xcode state.
|
|
[4PZ-EVK] Snapshot availability probe shells out to real xcrun and Xcode (additional location):
src/snapshot-tests/suites/xcode-ide-suite.ts#L70
The new helper invokes real `xcrun --find mcpbridge` and `pgrep -x Xcode` via `execSync` to gate snapshot tests. This couples the test suite to the host environment (real xcrun, a running Xcode app) instead of injected command/filesystem dependencies, violating the guardrail that unit/snapshot tests must not call real `xcrun`, devices, or simulators. Tests will behave differently across machines and CI, and they introduce hidden dependence on the developer's Xcode state.
|
|
Daemon xcode-ide.invoke bypasses shared bridge.callToolTool handler, creating a parallel invocation path:
src/daemon/daemon-server.ts#L67
The new `toolResponseToDaemonResult` and `toolErrorToDaemonResult` re-implement what `XcodeToolsBridgeStandaloneToolHandler.callToolTool` already does for the MCP path: it invokes `xcodeIdeService.invokeTool`, runs `callToolResultToBridgeResultWithArtifact`, and on error builds a `BridgeToolResult` with a `[code] message` envelope produced by `classifyBridgeError`. The daemon hunk calls `xcodeIdeService.invokeTool` directly and, on error, only sets `errorMessage` to `error.message` with no bridge error classification or `[code]` prefix. This violates the 'MCP, CLI, and daemon paths use shared handlers' and 'Avoid silent fallbacks and parallel invocation paths' guardrails, producing diverging error envelopes between the MCP and daemon transports for the same dynamic Xcode IDE tool.
|
|
Removal of daemon-runtime rethrow may change error propagation contract:
src/runtime/tool-invoker.ts#L599
The previous code rethrew errors when `opts.runtime === 'daemon'`, ensuring the daemon's outer caller observed the failure as a thrown exception. The new code unconditionally calls `emitExplicitRuntimeError` and swallows the error. If daemon callers rely on exceptions to detect direct handler failures (e.g. for transport-level error reporting or metrics outside this function), this is a backwards-incompatible side effect that could cause silent failures in the daemon path.
|