context-mode 1.0.143 → 1.0.144

package/.claude-plugin/marketplace.json

@@ -6,14 +6,14 @@
   },
   "metadata": {
     "description": "Claude Code plugins by Mert Koseoğlu",
-    "version": "1.0.143"
+    "version": "1.0.144"
   },
   "plugins": [
     {
       "name": "context-mode",
       "source": "./",
       "description": "Claude Code MCP plugin that saves 98% of your context window. Sandboxed code execution in 11 languages, FTS5 knowledge base with BM25 ranking, and intent-driven search.",
-      "version": "1.0.143",
+      "version": "1.0.144",
       "author": {
         "name": "Mert Koseoğlu"
       },

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "context-mode",
-  "version": "1.0.143",
+  "version": "1.0.144",
   "description": "MCP server that saves 98% of your context window with session continuity. Sandboxed code execution in 11 languages, FTS5 knowledge base with BM25 ranking, and automatic state restore across compactions.",
   "author": {
     "name": "Mert Koseoğlu",

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "context-mode",
-  "version": "1.0.143",
+  "version": "1.0.144",
   "description": "MCP server that saves 98% of your context window with session continuity. Sandboxed code execution in 11 languages, FTS5 knowledge base with BM25 ranking, and automatic state restore across compactions.",
   "author": {
     "name": "Mert Koseoğlu",

package/.openclaw-plugin/openclaw.plugin.json

@@ -3,7 +3,7 @@
   "name": "Context Mode",
   "kind": "tool",
   "description": "OpenClaw plugin that saves 98% of your context window. Sandboxed code execution in 11 languages, FTS5 knowledge base with BM25 ranking, and intent-driven search.",
-  "version": "1.0.143",
+  "version": "1.0.144",
   "sandbox": {
     "mode": "permissive",
     "filesystem_access": "full",

package/.openclaw-plugin/package.json

@@ -1,6 +1,6 @@
 {
   "name": "context-mode",
-  "version": "1.0.143",
+  "version": "1.0.144",
   "description": "OpenClaw plugin that saves 98% of your context window. Sandboxed code execution in 11 languages, FTS5 knowledge base with BM25 ranking, and intent-driven search.",
   "author": {
     "name": "Mert Koseoğlu",

package/build/adapters/pi/mcp-bridge.js

@@ -92,10 +92,16 @@ export function resolveJsRuntimeForBridge(deps = {}) {
         return execPath;
     return null;
 }
+// Bridge-imposed timeout for protocol-handshake methods (initialize,
+// tools/list). These MUST be bounded: a server that never replies to
+// initialize would otherwise block Pi's bridge bootstrap indefinitely.
+// `tools/call` deliberately has NO bridge ceiling (#643) — long-running
+// ctx_execute (test suites, builds, cargo test) was rejected by a 120s
+// hardcoded bound even though the executor child would have finished.
+// Responsibility for bounding a tool call belongs to the executor
+// layer (per-tool timeout / background mode / Pi-level cancel), not
+// to the transport.
 const DEFAULT_REQUEST_TIMEOUT_MS = 60_000;
-// Tools/call may run shell commands or fetch URLs — wider window than
-// initialize/list, but still bounded so a hung server can't block Pi.
-const DEFAULT_CALL_TIMEOUT_MS = 120_000;
 class PiTextComponent {
     text;
     constructor(text = "") {
@@ -349,19 +355,29 @@ export class MCPStdioClient {
             throw new Error("MCP client not started");
         const id = ++this.requestId;
         return new Promise((resolve, reject) => {
-            const timer = setTimeout(() => {
-                if (!this.pending.has(id))
-                    return;
-                this.pending.delete(id);
-                reject(new Error(`MCP request timeout after ${timeoutMs}ms: ${method}`));
-            }, timeoutMs);
+            // Gate the timer on a finite ms value so callers can pass
+            // `Number.POSITIVE_INFINITY` to mean "no bridge ceiling" (#643).
+            // Node coerces both `undefined` and `Infinity` to a 1ms delay
+            // (TimeoutOverflowWarning), so we can't just pass them through —
+            // we must skip the setTimeout entirely. tools/call uses this path
+            // because long-running ctx_execute must not be bounded here.
+            const timer = Number.isFinite(timeoutMs)
+                ? setTimeout(() => {
+                    if (!this.pending.has(id))
+                        return;
+                    this.pending.delete(id);
+                    reject(new Error(`MCP request timeout after ${timeoutMs}ms: ${method}`));
+                }, timeoutMs)
+                : null;
             this.pending.set(id, {
                 resolve: (v) => {
-                    clearTimeout(timer);
+                    if (timer)
+                        clearTimeout(timer);
                     resolve(v);
                 },
                 reject: (e) => {
-                    clearTimeout(timer);
+                    if (timer)
+                        clearTimeout(timer);
                     reject(e);
                 },
             });
@@ -445,7 +461,15 @@ export class MCPStdioClient {
         // one layer covers `listTools` / `initialize` paths too, with a
         // single-flight guard against orphan child processes from
         // concurrent callers.
-        return this.request("tools/call", { name, arguments: args ?? {} }, DEFAULT_CALL_TIMEOUT_MS);
+        //
+        // No bridge-imposed timeout for tools/call (#643). The previous
+        // 120s ceiling rejected legitimate long-running ctx_execute calls
+        // (test suites, builds, large `cargo test`) even though the
+        // executor child would have finished. Bounding belongs to the
+        // executor layer (per-tool timeout / background mode / Pi cancel),
+        // not the transport. `Number.POSITIVE_INFINITY` instructs
+        // `request()` to skip the setTimeout entirely — see the gate there.
+        return this.request("tools/call", { name, arguments: args ?? {} }, Number.POSITIVE_INFINITY);
     }
     /**
      * Respawn the MCP child after an exit (clean shutdown or crash).

package/build/server.d.ts

@@ -21,6 +21,41 @@ export declare function emitSuppressionDiagnostic(opts?: {
 }): void;
 /** Test-only: reset the one-shot emission flag so suites can re-exercise. */
 export declare function __resetSuppressionDiagnosticForTests(): void;
+/**
+ * Issue #637 — register an explicit empty `tools/list` handler on the McpServer.
+ *
+ * Background: when `suppressMcpToolsForNativePluginHost` is true, every
+ * `server.registerTool()` call is short-circuited (returns `undefined` above).
+ * The MCP SDK only installs the SDK-default `tools/list` handler when at least
+ * one `registerTool()` reaches `setToolRequestHandlers()` internally
+ * (mcp.js:56-67). Suppressing every registration leaves `tools/list`
+ * unregistered, and the framework's RPC layer answers it with
+ * `-32601 "Method not found"`.
+ *
+ * The reporter of #637 (SquirrelRat) inspected the suppressed child via
+ * `tools/list` and read the JSON-RPC error as "the plugin never registers any
+ * ctx_* tools" — when in fact the plugin DOES register all 11 tools natively
+ * (verified at `src/adapters/opencode/plugin.ts:469` and
+ * `tests/opencode-plugin.test.ts:88`). The misleading -32601 is the seed of
+ * the #637 perception.
+ *
+ * This helper installs an explicit handler that returns `{tools: []}` — a
+ * spec-compliant empty list. Paired with the existing #623 stderr diagnostic,
+ * an operator now sees:
+ *   - wire response: `{tools: []}` (matches expectation, no JSON-RPC error)
+ *   - stderr: `[context-mode] ctx_* tools/list intentionally empty… (#623)`
+ *
+ * Idempotent: throws inside SDK if called twice on the same server because
+ * `assertCanSetRequestHandler` (mcp.js:60) rejects duplicate registrations;
+ * we therefore install the SDK's default tool handlers FIRST (via a no-op
+ * registerTool of a fake tool, immediately removed) only if needed. To keep
+ * the public surface minimal, we just call `server.server.setRequestHandler`
+ * directly — that is the same low-level call used for prompts/resources at
+ * server.ts:259-261 and avoids the SDK guard entirely.
+ *
+ * Exported for test (#637 in-memory regression guard).
+ */
+export declare function registerEmptyToolsListHandler(target?: McpServer): void;
 type ToolContextOverride = {
     projectDir: string;
     sessionId?: string;

package/build/server.js

@@ -186,6 +186,44 @@ export function emitSuppressionDiagnostic(opts = {}) {
 export function __resetSuppressionDiagnosticForTests() {
     __suppressionDiagnosticEmitted = false;
 }
+/**
+ * Issue #637 — register an explicit empty `tools/list` handler on the McpServer.
+ *
+ * Background: when `suppressMcpToolsForNativePluginHost` is true, every
+ * `server.registerTool()` call is short-circuited (returns `undefined` above).
+ * The MCP SDK only installs the SDK-default `tools/list` handler when at least
+ * one `registerTool()` reaches `setToolRequestHandlers()` internally
+ * (mcp.js:56-67). Suppressing every registration leaves `tools/list`
+ * unregistered, and the framework's RPC layer answers it with
+ * `-32601 "Method not found"`.
+ *
+ * The reporter of #637 (SquirrelRat) inspected the suppressed child via
+ * `tools/list` and read the JSON-RPC error as "the plugin never registers any
+ * ctx_* tools" — when in fact the plugin DOES register all 11 tools natively
+ * (verified at `src/adapters/opencode/plugin.ts:469` and
+ * `tests/opencode-plugin.test.ts:88`). The misleading -32601 is the seed of
+ * the #637 perception.
+ *
+ * This helper installs an explicit handler that returns `{tools: []}` — a
+ * spec-compliant empty list. Paired with the existing #623 stderr diagnostic,
+ * an operator now sees:
+ *   - wire response: `{tools: []}` (matches expectation, no JSON-RPC error)
+ *   - stderr: `[context-mode] ctx_* tools/list intentionally empty… (#623)`
+ *
+ * Idempotent: throws inside SDK if called twice on the same server because
+ * `assertCanSetRequestHandler` (mcp.js:60) rejects duplicate registrations;
+ * we therefore install the SDK's default tool handlers FIRST (via a no-op
+ * registerTool of a fake tool, immediately removed) only if needed. To keep
+ * the public surface minimal, we just call `server.server.setRequestHandler`
+ * directly — that is the same low-level call used for prompts/resources at
+ * server.ts:259-261 and avoids the SDK guard entirely.
+ *
+ * Exported for test (#637 in-memory regression guard).
+ */
+export function registerEmptyToolsListHandler(target = server) {
+    target.server.registerCapabilities({ tools: { listChanged: false } });
+    target.server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: [] }));
+}
 const originalRegisterTool = server.registerTool.bind(server);
 server.registerTool = (...args) => {
     const [name, config, handler] = args;
@@ -196,6 +234,16 @@ server.registerTool = (...args) => {
     REGISTERED_CTX_TOOLS.push({ name, config, handler });
     return originalRegisterTool(...args);
 };
+// Issue #637 — when suppression is active, install the empty tools/list handler
+// once at module-init time so the suppressed MCP child responds with
+// `{tools: []}` instead of JSON-RPC `-32601 Method not found`. Pair with the
+// #623 stderr diagnostic that explains WHY the list is empty. Skipped for the
+// embedded plugin-import path because the embedded process is not the stdio
+// MCP child an operator would inspect — it lives inside the OpenCode/Kilo
+// host and never speaks JSON-RPC over stdio.
+if (suppressMcpToolsForNativePluginHost && process.env.CONTEXT_MODE_EMBEDDED_PLUGIN_TOOLS !== "1") {
+    registerEmptyToolsListHandler(server);
+}
 const projectDirOverride = new AsyncLocalStorage();
 export async function withProjectDirOverride(projectDir, fn) {
     const ctx = typeof projectDir === "string" ? { projectDir } : projectDir;
@@ -204,7 +252,7 @@ export async function withProjectDirOverride(projectDir, fn) {
 // Register empty prompts/resources handlers so MCP clients don't get -32601 (#168).
 // OpenCode calls listPrompts()/listResources() unconditionally — the error can poison
 // the SDK transport layer, causing subsequent listTools() calls to fail permanently.
-import { ListPromptsRequestSchema, ListResourcesRequestSchema, ListResourceTemplatesRequestSchema } from "@modelcontextprotocol/sdk/types.js";
+import { ListPromptsRequestSchema, ListResourcesRequestSchema, ListResourceTemplatesRequestSchema, ListToolsRequestSchema } from "@modelcontextprotocol/sdk/types.js";
 server.server.registerCapabilities({ prompts: { listChanged: false }, resources: { listChanged: false } });
 server.server.setRequestHandler(ListPromptsRequestSchema, async () => ({ prompts: [] }));
 server.server.setRequestHandler(ListResourcesRequestSchema, async () => ({ resources: [] }));