github · pluggedin-mcp-proxyad142dae1aac

Evidence

#!/usr/bin/env node

import { spawn, execFile } from 'child_process';

import { readFileSync } from 'fs';

import { fileURLToPath } from 'url';

import { dirname, join } from 'path';

const __filename = fileURLToPath(import.meta.url);

const __dirname = dirname(__filename);

console.log('🚀 Starting MCP Inspector with auto-open...');

// Load environment variables from .env.local with proper parsing

const envPath = join(__dirname, '..', '.env.local');

let envVars = {};

// Secure environment variable

RemediationAI

The problem is that inspector-simple.js reads PLUGGEDIN_API_KEY and PLUGGEDIN_API_BASE_URL from .env.local and passes them directly as environment variables to a spawned child process, exposing credentials to the subprocess and potentially to process inspection tools. Remove the DANGEROUSLY_OMIT_AUTH flag and instead use the `env` option in `spawn()` to pass only a minimal, sanitized environment—explicitly exclude credential variables or use a secrets management library like `dotenv-safe` to validate required keys before spawning. This ensures credentials are never passed to untrusted child processes and reduces the attack surface for credential exfiltration. Verify by running the inspector and confirming via `ps aux` or `cat /proc/[pid]/environ` that PLUGGEDIN_API_KEY and PLUGGEDIN_API_BASE_URL do not appear in the spawned process environment.

Evidence

#!/usr/bin/env node

import { spawn, execFile } from 'child_process';

import { readFileSync } from 'fs';

import { fileURLToPath } from 'url';

import { dirname, join } from 'path';

const __filename = fileURLToPath(import.meta.url);

const __dirname = dirname(__filename);

console.log('🚀 Starting Streamable HTTP MCP Server with Inspector...');

// Load environment variables from .env.local

const envPath = join(__dirname, '..', '.env.local');

let envVars = {};

// Secure environment variable parser

RemediationAI

The problem is that inspector-http.js reads PLUGGEDIN_API_KEY from .env.local and passes it as an environment variable to a spawned process that connects to an external MCP inspector endpoint without validating the endpoint URL, enabling credential exfiltration to attacker-controlled servers. Replace the direct environment variable passing with an in-process credential injection mechanism: use the `env` option in `spawn()` to exclude credential variables, and instead pass the API key only to validated, hardcoded endpoints via HTTPS with certificate pinning or mutual TLS. This prevents the credential from being leaked to arbitrary external destinations. Verify by inspecting the spawned process environment with `ps aux` and confirming the API key is absent, then test that the inspector still authenticates correctly to the intended endpoint.

Evidence

#!/usr/bin/env node

import { spawn, execFile } from 'child_process';

import { readFileSync } from 'fs';

import { fileURLToPath } from 'url';

import { dirname, join } from 'path';

const __filename = fileURLToPath(import.meta.url);

const __dirname = dirname(__filename);

console.log('🚀 Starting MCP Inspector with auto-open...');

// Load environment variables from .env.local with proper parsing

const envPath = join(__dirname, '..', '.env.local');

let envVars = {};

// Secure environment variable

RemediationAI

The problem is that inspector-auto.js reads PLUGGEDIN_API_KEY and PLUGGEDIN_API_BASE_URL from .env.local and passes them as environment variables to a spawned MCP inspector process without validating the destination endpoint, creating a credential exfiltration risk. Modify the `spawn()` call to use the `env` option with an explicit allowlist of safe environment variables, excluding all credential keys; instead, pass credentials through secure in-process channels (e.g., file descriptors, Unix sockets, or authenticated HTTP headers to a validated endpoint). This prevents credentials from leaking to unvalidated external services. Verify by checking the spawned process environment with `cat /proc/[pid]/environ` and confirming PLUGGEDIN_API_KEY and PLUGGEDIN_API_BASE_URL are absent, then confirm the inspector still functions with the intended backend.

Evidence

debugError(`Invalid command for server ${serverParams.name}: ${serverParams.command}`);

      return { client: undefined, transport: undefined };

    }

    const stdioParams: StdioServerParameters = {

      command: serverParams.command,

      args: serverParams.args ? validateArgs(serverParams.args) : undefined,

      env: serverParams.env ? validateEnv(serverParams.env) : undefined,

      // Use default values for other optional properties

      // stderr and cwd will use their default values

RemediationAI

The problem is that `createPluggedinMCPClient()` uses module-level `serverParams.url` to construct `SSEClientTransport` without consulting per-request caller identity or authorization context, allowing multiple callers to share the same transport and enabling confused deputy attacks where one caller's request can be attributed to or executed by another. Refactor the function signature to accept a `callerContext` or `requestContext` parameter containing the caller's identity and authorization scope, then validate that the caller is authorized to access the specific `serverParams.url` before constructing the transport; store per-caller transports in a context-keyed cache (e.g., `Map<string, Client>` keyed by caller ID). This ensures each caller's requests are isolated and authorized independently. Verify by creating two separate caller contexts with different permissions and confirming that a low-privilege caller cannot access resources authorized only for a high-privilege caller.

Evidence

for (const [key, value] of Object.entries(env)) {

    // Only allow valid environment variable names

    if (/^[A-Z0-9_]+$/i.test(key)) {

      // Sanitize the value to prevent injection

      validated[key] = String(value).replace(/[\0\r\n]/g, '');

    }

  }

  return validated;

}

export const createPluggedinMCPClient = (

  serverParams: ServerParameters

): { client: Client | undefined; transport: Transport | undefined } => {

  let transport: Transport | undefined;

  // Create the appropriate 

RemediationAI

The problem is that `createPluggedinMCPClient()` uses module-level `serverParams` to construct `StdioClientTransport` without consulting per-request caller identity or authorization context, enabling confused deputy attacks when multiple callers share the same MCP server instance. Refactor the function to accept a `callerContext` parameter (containing caller identity and authorization scope), then validate the caller's permissions against the requested `serverParams` before constructing the transport; maintain per-caller transport instances in a context-keyed cache to prevent request mixing. This ensures each caller's stdio transport is isolated and authorized independently. Verify by instantiating the client with two different caller contexts and confirming that commands from one caller do not leak into or affect the other caller's transport stream.

Evidence

#!/usr/bin/env node

import { spawn, execFile } from 'child_process';

import { readFileSync } from 'fs';

import { fileURLToPath } from 'url';

import { dirname, join } from 'path';

const __filename = fileURLToPath(import.meta.url);

const __dirname = dirname(__filename);

console.log('🚀 Starting Streamable HTTP MCP Server with Inspector...');

// Load environment variables from .env.local

const envPath = join(__dirname, '..', '.env.local');

let envVars = {};

// Secure environment variable parser

RemediationAI

The problem is that inspector-http.js spawns an MCP server and polls its /health endpoint, but the file is truncated mid-execution, preventing verification of the complete handler logic for remote code execution or dynamic behavior swapping patterns. Provide the complete, untruncated source code of inspector-http.js so that the full request/response handling, environment variable usage, and any dynamic reconfiguration logic can be audited for injection vulnerabilities, credential leakage, and unsafe deserialization. This enables a complete security review of the health-check polling mechanism and any side effects it may trigger. Verify by running a full static analysis scan (e.g., `npm audit`, ESLint with security plugins) on the complete file and confirming no new vulnerabilities are introduced.

Evidence

import { Client } from "@modelcontextprotocol/sdk/client/index.js";

import {

  StdioClientTransport,

  StdioServerParameters,

} from "@modelcontextprotocol/sdk/client/stdio.js";

import { SSEClientTransport } from "@modelcontextprotocol/sdk/client/sse.js";

import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";

import { Transport } from "@modelcontextprotocol/sdk/shared/transport.js";

import { ServerParameters } from "./types.js";

import { createRequire

RemediationAI

The problem is that `client.ts` `createPluggedinMCPClient()` function validates and constructs transport objects but is truncated mid-execution, preventing verification of the complete handler and any dynamic transport reconfiguration logic that could introduce vulnerabilities. Provide the complete, untruncated source code of `client.ts` including the full function body, error handlers, and any dynamic transport switching or reconfiguration logic so that the entire flow can be audited for confused deputy attacks, credential injection, and unsafe state management. This enables comprehensive security review of transport lifecycle and caller isolation. Verify by running a full static analysis scan (e.g., TypeScript strict mode, ESLint with security plugins) on the complete file and confirming no new vulnerabilities are introduced.

Evidence

/**

 * Streamable HTTP Server Transport for MCP Proxy

 *

 * MCP Protocol Compliance:

 * - Headers use Title-Case per MCP spec (Mcp-Session-Id, Mcp-Protocol-Version)

 * - CORS headers expose custom headers to clients

 * - Protocol version validation (2024-11-05)

 * - JSON-RPC 2.0 compliant error codes

 *

 * JSON-RPC Error Codes Used:

 * - -32600: Invalid Request (malformed request, unsupported protocol version)

 * - -32601: Method not found (HTTP method not allowed)

 * - -32603: Internal error (s

RemediationAI

The problem is that the HTTP route handling MCP `tools/list` has no authentication middleware applied, allowing anonymous clients to enumerate all exposed tools and scope the attack surface. Apply authentication middleware at the route or router level: for Express, add `passport.authenticate('jwt')` or a custom `requireAuth` middleware before the route handler; for FastAPI, add `Depends(verify_jwt)` to the route function signature; for Flask, use `@login_required` or a custom `@require_auth` decorator. This ensures only authenticated and authorized callers can enumerate tools. Verify by making an unauthenticated HTTP request to the `tools/list` endpoint and confirming it returns a 401 Unauthorized or 403 Forbidden response, then repeat with valid credentials and confirm the tool list is returned.

Evidence

query: validatedArgs.query,

        includeMetadata: true // Always request metadata

      };

      console.error(`[DEBUG] Request body:`, JSON.stringify(requestBody));

      const response = await axios.post(

        ragApiUrl,

RemediationAI

The problem is that user-controlled values are printed to the terminal via `console.error()` without ANSI escape sequence sanitization, allowing malicious input to inject cursor-control sequences that rewrite earlier output or hide shell commands. Replace the direct `console.error()` call with a sanitized output function that strips or escapes ANSI control characters: use a library like `chalk` with `.stripColor()` or implement a simple regex filter `/\x1b\[[0-9;]*m/g` to remove escape sequences before logging. This prevents terminal injection attacks. Verify by passing a string containing ANSI escape codes (e.g., `\x1b[2J` to clear screen) to the debug output and confirming the terminal is not cleared or manipulated.

Evidence

attempts++;

    try {

      // Try to connect to the health endpoint

      const response = await fetch(`http://localhost:${port}/health`);

      if (response.ok) {

        console.log(`✅ Server is ready! (took ${Date.now() - startTime}ms, ${attempts} attempts)`);

        return true;

RemediationAI

The problem is that the `fetch()` call to the health endpoint in inspector-http.js has no explicit timeout, allowing a malicious or hung upstream server to pin threads and exhaust connection pools, making the MCP server unresponsive. Add an explicit timeout to the `fetch()` call using the `AbortController` API: create an `AbortController`, set a timeout (e.g., 5 seconds) that calls `controller.abort()`, and pass `{ signal: controller.signal }` to the `fetch()` options. This ensures the health check fails fast if the upstream is unresponsive. Verify by starting the health check against a non-responsive server (e.g., `nc -l 127.0.0.1 9999` without responding) and confirming the fetch times out within the specified duration.

Evidence

// Define the schema for asking questions to the knowledge base

export const AskKnowledgeBaseInputSchema = z.object({

  query: z.string()

    .min(1, "Query cannot be empty")

    .max(1000, "Query too long")

    .describe("Question to ask the knowledge base")

RemediationAI

The problem is that the `query` field in `AskKnowledgeBaseInputSchema` is an unconstrained string that could accept arbitrary input, widening the tool's blast radius beyond its intended use. The schema already includes `.min(1)` and `.max(1000)` constraints, but add a `.regex()` pattern to restrict the query to safe characters: for example, `.regex(/^[a-zA-Z0-9\s\-.,?!]+$/, 'Query contains invalid characters')` to allow only alphanumeric, spaces, and basic punctuation. This prevents injection of special characters that could be misinterpreted by the knowledge base backend. Verify by attempting to pass a query with SQL keywords (e.g., `'; DROP TABLE--`) and confirming the schema validation rejects it.

Evidence

// Define the schema for asking questions to the knowledge base

const AskKnowledgeBaseInputSchema = z.object({

  query: z.string()

    .min(1, "Query cannot be empty")

    .max(1000, "Query too long")

    .describe("Your question or query to get AI-generated answers from the knowledge base.")

RemediationAI

The problem is that the `query` field in the `AskKnowledgeBaseInputSchema` in mcp-proxy.ts is an unconstrained string that could accept arbitrary input, widening the tool's blast radius. The schema already includes `.min(1)` and `.max(1000)` constraints, but add a `.regex()` pattern to restrict the query to safe characters: for example, `.regex(/^[a-zA-Z0-9\s\-.,?!]+$/, 'Query contains invalid characters')` to allow only alphanumeric, spaces, and basic punctuation. This prevents injection of special characters that could be misinterpreted by downstream systems. Verify by attempting to pass a query with shell metacharacters (e.g., `$(whoami)`) and confirming the schema validation rejects it.

Evidence

# Build stage

FROM node:20-slim AS builder

WORKDIR /app

# Copy package files

COPY package*.json ./

# Install all dependencies (including dev dependencies for building)

RUN npm ci

# Copy source code

COPY . .

# Build the application

RUN npm run build

# Production stage

FROM node:20-slim

WORKDIR /app

# Copy package files

COPY package*.json ./

# Install only production dependencies

RUN npm ci --only=production

# Copy built application from builder stage

COPY --from=builder /app/dist ./dist

RemediationAI

The problem is that the Dockerfile never sets a non-root `USER` directive, so the container runs as root by default, giving any RCE or library vulnerability full system privileges. Add a `USER` directive before the `CMD` or `ENTRYPOINT` in the final production stage: for example, add `RUN useradd -m -u 1000 appuser` after the `WORKDIR` line and then `USER 1000` before `CMD`. This ensures the MCP server runs with minimal privileges. Verify by building the image, running it, and executing `id` inside the container to confirm the process runs as UID 1000 (or the chosen non-root user) rather than UID 0 (root).

Evidence

import axios, { type AxiosResponse } from "axios";

import { ToolExecutionResult } from "../types.js";

import { 

  getPluggedinMCPApiKey, 

  getPluggedinMCPApiBaseUrl, 

  sanitizeName, 

  isDebugEnabled 

} from "../utils.js";

import { logMcpActivity, createExecutionTimer } from "../notification-logger.js";

import { debugError, debugLog } from "../debug-log.js";

import { getApiKeySetupMessage } from "./static-handlers-helpers.js";

import {

  DiscoverToolsInputSchema,

  AskKnowledgeBaseInputSchema,

RemediationAI

The problem is that the MCP manifest in src/handlers/static-handlers.ts declares tools but does not explicitly declare an authentication mechanism (none of: auth, authorization, bearer, oauth, mtls, apiKey, api_key, basic, token, authToken), making it unclear whether the server relies on network-layer, host-level, or application-level auth. Add an explicit `auth` field to the manifest JSON or tool definitions: for example, `"auth": { "type": "bearer", "scheme": "Bearer" }` or `"auth": { "type": "apiKey", "in": "header", "name": "X-API-Key" }`. This makes the authentication mechanism explicit and auditable. Verify by reviewing the manifest JSON output and confirming the `auth` field is present and accurately describes the actual authentication mechanism used by the server.

Evidence

# Migration Guide: Pre-release to v1.0.0

This guide helps you upgrade your plugged.in MCP Proxy from pre-release versions to the stable v1.0.0.

## Overview

Version 1.0.0 is our first stable release, bringing together all the features developed during the pre-release phase with enhanced security, notifications, and developer tools.

## What's New in v1.0.0

- **Notification Support**: Real-time activity tracking

- **RAG Integration**: Document context in AI interactions

- **Enhanced Security**

RemediationAI

The problem is that the MCP manifest referenced in MIGRATION_GUIDE_v1.0.0.md does not explicitly declare an authentication mechanism, making it unclear how the server authenticates callers. Add an explicit `auth` field to the manifest or documentation: for example, document that the server uses "Bearer token authentication" or "API key in X-API-Key header" and include this in the manifest JSON under an `auth` field. This ensures reviewers can audit the authentication mechanism. Verify by reviewing the migration guide and confirming it explicitly documents the authentication method used by the v1.0.0 server.

Evidence

# Release Notes - v1.0.0

Released: June 19, 2025

## 🎉 Overview

We're excited to announce the release of plugged.in MCP Proxy v1.0.0! This major update brings significant enhancements including notification support, RAG integration capabilities, enhanced security measures, and improved debugging tools.

## ✨ New Features

### 🔔 MCP Activity Notifications

- **Real-time Activity Logging**: Track all MCP operations (tool calls, resource reads, prompt executions)

- **Notification Integration**: Se

RemediationAI

The problem is that the MCP manifest referenced in RELEASE_NOTES_v1.0.0.md does not explicitly declare an authentication mechanism, making it unclear how the server authenticates callers. Add an explicit `auth` field to the manifest or release notes: for example, document that the server uses "OAuth 2.0" or "JWT bearer tokens" and include this in the manifest JSON under an `auth` field. This ensures reviewers can audit the authentication mechanism. Verify by reviewing the release notes and confirming they explicitly document the authentication method used by the v1.0.0 server.

Evidence

# plugged.in MCP Hub — Proxy · Knowledge · Memory · Tools

<div align="center">

  <img src="https://plugged.in/_next/image?url=%2Fpluggedin-wl.png&w=256&q=75" alt="plugged.in Logo" width="256" height="75">

  <h3>The Crossroads for AI Data Exchanges</h3>

  <p>A unified MCP hub that gives your AI <strong>Knowledge</strong>, <strong>Memory</strong>, and <strong>Tools</strong> — not just a proxy. Manage and test all MCP servers from a single connection while powering document-aware and memory-augmen

RemediationAI

The problem is that the MCP manifest referenced in README.md does not explicitly declare an authentication mechanism, making it unclear how the server authenticates callers. Add an explicit `auth` field to the manifest or README documentation: for example, document that the server uses "API key authentication" or "JWT bearer tokens" and include this in the manifest JSON under an `auth` field. This ensures reviewers and users can audit the authentication mechanism. Verify by reviewing the README and confirming it explicitly documents the authentication method used by the MCP server.

Evidence

# Release Notes: v1.4.0 - Registry v2 Support & Enhanced OAuth Integration

## 🎉 Overview

We're excited to announce the release of plugged.in MCP Proxy v1.4.0! This release brings full support for the Registry v2 features from plugged.in App v2.7.0, including OAuth token management, bidirectional notifications, and trending analytics.

## 🚀 Major Features

### 1. OAuth Token Management

- **Seamless Authentication**: OAuth tokens are now automatically retrieved from plugged.in App v2.7.0

- **No 

RemediationAI

The problem is that the MCP manifest referenced in RELEASE_NOTES_v1.4.0.md does not explicitly declare an authentication mechanism, making it unclear how the server authenticates callers. Add an explicit `auth` field to the manifest or release notes: for example, document that the server uses "OAuth 2.0 token management" (as mentioned in the release notes) and include this in the manifest JSON under an `auth` field with details like `"type": "oauth2"`. This ensures reviewers can audit the authentication mechanism. Verify by reviewing the release notes and confirming they explicitly document the OAuth 2.0 authentication method in the manifest.

Evidence

actions: read # Required for Claude to read CI results on PRs

    steps:

      - name: Checkout repository

        uses: actions/checkout@v4

        with:

          fetch-depth: 1

RemediationAI

The problem is that `.github/workflows/claude.yml` uses `actions/checkout@v4`, which is a mutable tag that can be rewritten by a compromised maintainer, allowing malicious code injection into the CI pipeline. Replace `uses: actions/checkout@v4` with a pinned commit SHA: `uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v4.1.1`. Use a tool like `pinact` or `ratchet` to automate this process across all workflows. This ensures the exact version of the action is immutable and cannot be silently replaced. Verify by running `git log --oneline .github/workflows/claude.yml` and confirming the `uses:` line contains a 40-character SHA, not a tag.

Evidence

steps:

      - name: Checkout repository

        uses: actions/checkout@v4

        with:

          fetch-depth: 1

RemediationAI

The problem is that `.github/workflows/claude-code-review.yml` uses `actions/checkout@v4`, which is a mutable tag that can be rewritten by a compromised maintainer, allowing malicious code injection into the CI pipeline. Replace `uses: actions/checkout@v4` with a pinned commit SHA: `uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v4.1.1`. This ensures the exact version of the action is immutable. Verify by inspecting the workflow file and confirming the `uses:` line contains a 40-character SHA instead of a tag.

Evidence

- name: Run Claude Code Review

        id: claude-review

        uses: anthropics/claude-code-action@v1

        with:

          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

          prompt: |

RemediationAI

The problem is that `.github/workflows/claude-code-review.yml` uses `anthropics/claude-code-action@v1`, which is a mutable tag that can be rewritten by a compromised maintainer, allowing malicious code injection into the CI pipeline. Replace `uses: anthropics/claude-code-action@v1` with a pinned commit SHA: `uses: anthropics/claude-code-action@<40-char-sha> # v1.x.x`. Use a tool like `pinact` to automate this process. This ensures the exact version of the action is immutable and cannot be silently replaced. Verify by inspecting the workflow file and confirming the `uses:` line contains a 40-character SHA instead of a tag.

Evidence

- name: Run Claude Code

        id: claude

        uses: anthropics/claude-code-action@v1

        with:

          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

RemediationAI

The problem is that `.github/workflows/claude.yml` uses `anthropics/claude-code-action@v1`, which is a mutable tag that can be rewritten by a compromised maintainer, allowing malicious code injection into the CI pipeline. Replace `uses: anthropics/claude-code-action@v1` with a pinned commit SHA: `uses: anthropics/claude-code-action@<40-char-sha> # v1.x.x`. Use a tool like `pinact` to automate this process. This ensures the exact version of the action is immutable. Verify by inspecting the workflow file and confirming the `uses:` line contains a 40-character SHA instead of a tag.

Evidence

import { z } from "zod";

import { Server } from "@modelcontextprotocol/sdk/server/index.js";

import {

  CompatibilityCallToolResultSchema,

  ListToolsResultSchema,

  Tool,

} from "@modelcontextprotocol/sdk/types.js";

import { getMcpServers } from "../fetch-pluggedinmcp.js";

import { getSessionKey, sanitizeName, getPluggedinMCPApiKey, getPluggedinMCPApiBaseUrl } from "../utils.js"; // Import API utils

import axios from "axios"; // Import axios

import { getSession } from "../sessions.js";

import {

RemediationAI

The problem is that the tool description in src/tools/call-pluggedin-tool.ts may contain imperative phrases directing the LLM to invoke other tools (e.g., 'invoke the write_file tool'), enabling cross-tool chaining injection where a caller authorized for one tool can escalate into others. Review the tool description and remove any imperative phrases that direct the LLM to call other tools; instead, describe only what THIS tool does (e.g., 'Calls a Plugged.in tool with the specified parameters'). This prevents the LLM from being tricked into invoking unauthorized tools. Verify by reviewing the tool description in the MCP manifest and confirming it contains no phrases like 'invoke', 'call', 'also use', or 'before using this'.

Evidence

/**

 * Express Middleware for MCP Streamable HTTP Server

 *

 * This module contains reusable middleware functions for:

 * - CORS headers

 * - Protocol version validation

 * - Accept header normalization

 * - Authentication

 * - Static file serving for .well-known endpoints

 */

import express, { RequestHandler } from 'express';

import { StreamableHTTPServerTransport } from '@modelcontextprotocol/sdk/server/streamableHttp.js';

import { Server } from '@modelcontextprotocol/sdk/server/index.js';

im

RemediationAI

The problem is that the MCP server in src/middleware.ts has authentication wired but no invocation log, making it impossible to detect, attribute, or reconstruct unauthorized actions after the fact. Add structured logging to every authenticated tool handler: call `logger.info('tool.invoke', { toolName, callerId, requestId, timestamp, args })` before executing the tool, and log the result and any errors after execution. Ship these logs to a retention sink (CloudWatch, Datadog, ELK stack). This enables forensic analysis and compliance auditing. Verify by invoking an authenticated tool and confirming a structured log entry appears in the logging sink with the tool name, caller identity, and request ID.

Evidence

if (retry) {

        try {

          await client.close();

        } catch {}

        await sleep(waitFor);

      }

    }

RemediationAI

The problem is that src/client.ts silently swallows the exception in the `catch {}` block when closing the client, discarding the error with no log, metric, or trace, which blinds incident response and hides real failures. Replace `catch {}` with `catch (err) { logger.debug('client.close() error', { error: err.message }); }` to log the error at an appropriate level. This ensures failures are visible for debugging and monitoring. Verify by intentionally triggering a close error (e.g., by closing the transport twice) and confirming a debug log entry is produced.

Evidence

if (metadata) {

      try {

        metadata.transport.close().catch(() => {});

      } catch {}

      sessions.delete(oldestSessionId);

      debugLog(`Evicted oldest session ${oldestSessionId} (LRU eviction)`);

    }

RemediationAI

The problem is that src/middleware.ts silently swallows exceptions in the `.catch(() => {})` and `catch {}` blocks when closing transport metadata, discarding errors with no log or trace, which blinds incident response. Replace `.catch(() => {})` with `.catch(err => logger.debug('transport.close() error', { error: err.message }))` and replace `catch {}` with `catch (err) { logger.debug('session cleanup error', { error: err.message }); }`. This ensures failures are visible for debugging. Verify by intentionally triggering a close error and confirming a debug log entry is produced in the middleware logs.