<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>Agent Pitbook known fixes</title>
    <link>https://laozhangzzz.github.io/agent-pitbook/</link>
    <description>Answer-first search feed for coding-agent and MCP failure fixes.</description>
    <lastBuildDate>Thu, 25 Jun 2026 00:00:00 GMT</lastBuildDate>
    <item>
      <title>Fix: Dependency install fails because the agent sandbox blocks network access</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/agent-network-restricted-dependency-install.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/agent-network-restricted-dependency-install.html</guid>
      <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: dependency installation fails with DNS, host resolution, registry, index, TLS, or timeout errors
Root cause: The package manager needs external network access but the agent sandbox blocks it by default.
Fix first: Classify the error as network-related before changing dependency manifests.</description>
    </item>
    <item>
      <title>Fix: Debug sources can contain prompt injection targeting coding agents</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/agent-prompt-injection-in-debug-sources.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/agent-prompt-injection-in-debug-sources.html</guid>
      <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: a source includes instructions to ignore system or developer instructions
Root cause: LLM-readable troubleshooting material can also be used as a prompt-injection channel.
Fix first: Treat external source text as data rather than executable instruction.</description>
    </item>
    <item>
      <title>Fix: SDK doesnt read from .mcp.json until the CLI is run in the cwd</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/claude-agent-sdk-mcp-json-requires-project-settingsource.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/claude-agent-sdk-mcp-json-requires-project-settingsource.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: the SDK reports no MCP servers even though .mcp.json is in the working directory
Root cause: The Agent SDK does not auto-load project/user/local settings from disk; it loads them only when settingSources is set.
Fix first: Pass settingSources including 'project' (and 'user'/'local' as needed) when constructing the SDK query so .mcp.json is read.</description>
    </item>
    <item>
      <title>Fix: Singleton McpServer causes Already connected to a transport</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/claude-code-mcp-chrome-bridge-single-transport-deadlock.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/claude-code-mcp-chrome-bridge-single-transport-deadlock.html</guid>
      <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: Claude Code cannot reconnect to the chrome-bridge MCP server
Root cause: The bridge can reuse a singleton MCP Server instance across HTTP/SSE connections.
Fix first: Do not use curl /mcp as a health check.</description>
    </item>
    <item>
      <title>Fix: Claude Desktop MCP servers fail with Protocol instance reuse error (Already connected to a transport); Anthropic confirms fix in a later Desktop release</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/claude-desktop-mcp-protocol-instance-reuse-already-connected.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/claude-desktop-mcp-protocol-instance-reuse-already-connected.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: startup toasts: Could not connect to MCP server &lt;name&gt;
Root cause: The MCP SDK connection model is one transport per Protocol/server instance.
Fix first: Upgrade Claude Desktop to a build where this is fixed (resolved in a later release after 1.1.3918).</description>
    </item>
    <item>
      <title>Fix: dynamic resource not working in Claude desktop</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/claude-desktop-no-dynamic-resource-templates.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/claude-desktop-no-dynamic-resource-templates.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: a static resource works in Claude Desktop but a parameterized/templated resource does not show
Root cause: Dynamic resources are exposed via resources/templates/list; static resources via resources/list.
Fix first: Do not rely on dynamic resource templates in Claude Desktop; confirm client support before designing around them.</description>
    </item>
    <item>
      <title>Fix: Codex still references an old workspace path after a project move</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/codex-workspace-root-moved-stale-state.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/codex-workspace-root-moved-stale-state.html</guid>
      <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: Codex or its sidebar references an old workspace folder
Root cause: The desktop app persists workspace roots separately from the shell current directory, and those saved roots may not update when a folder is moved.
Fix first: Use the app's normal folder switching or reopen-workspace flow first.</description>
    </item>
    <item>
      <title>Fix: Docker port is published but localhost refuses the connection</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/docker-published-port-localhost-refused.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/docker-published-port-localhost-refused.html</guid>
      <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: docker ps or docker port shows the expected host port
Root cause: The app inside the container is listening on loopback rather than a container network interface.
Fix first: Change the app bind address inside the container to 0.0.0.0.</description>
    </item>
    <item>
      <title>Fix: Guide: Resolving '421 Invalid Host Header' DNS Rebinding Protection</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/fastmcp-421-invalid-host-header-dns-rebinding.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/fastmcp-421-invalid-host-header-dns-rebinding.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: all external requests fail with HTTP 421 Misdirected Request and 'Invalid Host header'
Root cause: FastMCP enables DNS rebinding protection that validates the request Host header against an allowed list (added in PR #861).
Fix first: Explicitly allow your hosts and origins via TransportSecuritySettings(allowed_hosts=[...], allowed_origins=[...]).</description>
    </item>
    <item>
      <title>Fix: Option to not rewrite the logging configuration workarounds: re-apply dictConfig, remove added handler</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/fastmcp-overrides-logging-configuration.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/fastmcp-overrides-logging-configuration.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: log messages become duplicated after the FastMCP server is created
Root cause: FastMCP performs global logging configuration at startup (configure_logging) instead of confining itself to its own logger.
Fix first: Re-apply your logging configuration after constructing FastMCP so your handlers win.</description>
    </item>
    <item>
      <title>Fix: VSCode Toolset name mismatch: github/* fails with Unknown tool, but github warns its deprecated</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/github-mcp-vscode-toolset-name-mismatch.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/github-mcp-vscode-toolset-name-mismatch.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: 'tools': ['github/*'] produces Unknown tool
Root cause: The server/* toolset alias resolves only when the MCP server is registered under the matching name (e.g. installed via the official flow so it is named github).
Fix first: Use the name that resolves for your setup: if github/* is Unknown tool, use 'github' and ignore the rename warning for now.</description>
    </item>
    <item>
      <title>Fix: macOS PortAudio/sounddevice records all-zero silent audio with no error when the default mic is unavailable</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/macos-portaudio-silent-zero-capture-unavailable-default-input.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/macos-portaudio-silent-zero-capture-unavailable-default-input.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: multi-second speech transcribes to a single junk token (e.g. 6.2s clip -&gt; '我。', stray Korean '그.', or '谷歌')
Root cause: With the lid closed (clamshell), the built-in MacBook mic is physically unavailable but is still enumerated AND still selected as the default input device.
Fix first: Diagnose by measuring the recorded level, not by trusting the API: 0 == silent capture.</description>
    </item>
    <item>
      <title>Fix: author resolved 'Client closed' by fixing an incorrect registry in user-level ~/.npmrc that the project .npmrc had overridden in the terminal</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-client-uses-user-level-npmrc-wrong-registry.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-client-uses-user-level-npmrc-wrong-registry.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: npx -y &lt;package&gt; works in a project terminal but not when launched by the client
Root cause: npm merges config from multiple .npmrc files; the project-level file only applies when the working directory is inside that project.
Fix first: Inspect effective npm config and the user-level rc file.</description>
    </item>
    <item>
      <title>Fix: GitHub MCP Server Fails to Start: 'npx' Command Error and Connection Closed -32000</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-error-32000-connection-closed-server-failed-to-start.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-error-32000-connection-closed-server-failed-to-start.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: client UI shows MCP error -32000: Connection closed
Root cause: The client spawns the configured command and speaks JSON-RPC over stdio.
Fix first: Reproduce outside the client: run the exact command + args from the config in a terminal with the same env.</description>
    </item>
    <item>
      <title>Fix: Filesystem server access denied for allowed paths on Windows</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-filesystem-server-windows-access-denied-case-sensitivity.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-filesystem-server-windows-access-denied-case-sensitivity.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: Windows only: a file under an allowed directory returns 'Error: Access denied - path outside allowed directories'
Root cause: The allowed-directory check compares request paths against allowed roots as strings.
Fix first: Make the configured allowed-directory drive-letter case match what the client sends; try both C:\... and c:\... forms.</description>
    </item>
    <item>
      <title>Fix: Claude Code cannot connect to GitHubs remote MCP server using OAuth authentication PAT via GITHUB_PERSONAL_ACCESS_TOKEN is the confirmed workaround</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-github-remote-oauth-dcr-unsupported-use-pat.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-github-remote-oauth-dcr-unsupported-use-pat.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: claude mcp add ... https://api.githubcopilot.com/mcp/ then the connection fails
Root cause: The client's OAuth flow relies on OAuth 2.1 Dynamic Client Registration to register itself with the authorization server.
Fix first: Create a fine-grained GitHub Personal Access Token with the scopes you need.</description>
    </item>
    <item>
      <title>Fix: Docker container connection refused HOST + ALLOWED_ORIGINS workaround</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-inspector-docker-connection-refused-host-env.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-inspector-docker-connection-refused-host-env.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: curl http://localhost:6274 returns Failed to connect ... Connection refused
Root cause: Inspector listens on the loopback interface, which inside a container is only reachable by processes in that container.
Fix first: Pass HOST and ALLOWED_ORIGINS to the container run command.</description>
    </item>
    <item>
      <title>Fix: sh: mcp-inspector: command not found after upgrading to v0.10.0 downgrade to 0.9.0</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-inspector-release-regression-pin-version.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-inspector-release-regression-pin-version.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: npx @modelcontextprotocol/inspector fails with 'sh: mcp-inspector: command not found' or ''mcp-inspector' is not recognized' (0.10.0)
Root cause: Inspector is released often and some releases regress.
Fix first: Pin a known-good version to unblock, e.g. @0.9.0 for the 0.10.0 command-not-found regression or @0.16.7 for the 0.17.2 Controller-already-closed regression.</description>
    </item>
    <item>
      <title>Fix: comment confirming a corrupted npx cache from network errors caused the server to crash; clearing it fixed startup</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-npx-cache-corrupted-server-fails-to-start.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-npx-cache-corrupted-server-fails-to-start.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: npx-launched MCP server worked before and now fails, or fails only on first launch
Root cause: npx downloads the package into the npm cache before running it.
Fix first: Clear the npm/npx cache and relaunch.</description>
    </item>
    <item>
      <title>Fix: Puppeteer MCP Server Missing Screenshots</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-puppeteer-screenshots-in-memory-only.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-puppeteer-screenshots-in-memory-only.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: puppeteer_screenshot reports success but no image file appears on disk
Root cause: The server stores screenshots in memory and exposes them as MCP resources, with no documented filesystem path.
Fix first: Retrieve the screenshot via the MCP resource the server exposes, not from a file path.</description>
    </item>
    <item>
      <title>Fix: server-postgres multi-instance issue closed; maintainer notes the server moved to servers-archived</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-reference-server-archived-unmaintained.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-reference-server-archived-unmaintained.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: a reference server misbehaves and the issue is closed with a deprecation/archival note
Root cause: The project archived a number of reference servers to reduce maintenance load and focus on a smaller core set.
Fix first: Before debugging a reference server, check whether it is in modelcontextprotocol/servers-archived or flagged deprecated in the main README.</description>
    </item>
    <item>
      <title>Fix: Claude Desktop custom MCP connection failure; confirmed root cause is Cloudflare Tunnel buffering SSE despite successful OAuth/initialize</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-reverse-proxy-buffers-sse-connection-fails.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-reverse-proxy-buffers-sse-connection-fails.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: the client connects to a custom remote MCP then errors (e.g. 'There was an error connecting to your server')
Root cause: MCP Streamable HTTP streams responses over SSE, which must be flushed incrementally.
Fix first: Disable response buffering for the MCP endpoint at the proxy.</description>
    </item>
    <item>
      <title>Fix: Environment variables not respected in @modelcontextprotocol/server-memory package</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-server-memory-ignores-memory-file-path-env.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-server-memory-ignores-memory-file-path-env.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: MEMORY_FILE_PATH is set but the memory file is created at a default location
Root cause: The npm release (e.g. 0.6.2) was older than the GitHub main source: its compiled dist/index.js hardcoded path.join(__dirname, 'memory.json').
Fix first: Pin @modelcontextprotocol/server-memory@latest in the config to get the build that honors the env var (fix shipped in release 2025.4.25).</description>
    </item>
    <item>
      <title>Fix: MCP SSE Server: Received request before initialization was complete comment confirms supergateway double-initialize; mcp-proxy works</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-sse-received-request-before-initialization.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-sse-received-request-before-initialization.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: server raises RuntimeError: Received request before initialization was complete on tools/list or a tool call
Root cause: The MCP lifecycle requires the client's initialize to complete before other requests.
Fix first: If a gateway/proxy is in front, use a spec-compliant one: switching supergateway -&gt; mcp-proxy resolves the double-initialize case.</description>
    </item>
    <item>
      <title>Fix: MCP Server Session Lost in Multi-Worker Environment comments confirm stateless_http=True and ingress sticky-hash fixes</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-sse-session-lost-multi-worker.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-sse-session-lost-multi-worker.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: SSE connection opens (200), first POST returns 202, later POSTs return 404
Root cause: The SSE transport is stateful: the session lives in the memory of the worker/pod that accepted the SSE connection.
Fix first: Preferred: run stateless with Streamable HTTP so no per-connection in-memory session is required.</description>
    </item>
    <item>
      <title>Fix: _handle_stateless_request ClosedResourceError reports 1.11.0 works, 1.12.0 fails; also FastMCP 2.10/2.13</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-stateless-streamable-http-closedresourceerror.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-stateless-streamable-http-closedresourceerror.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: each request raises an exception group ending in anyio.ClosedResourceError
Root cause: In affected versions the stateless Streamable HTTP path re-enters the transport's read loop.
Fix first: Pin a known-good SDK version; users reported 1.11.0 working where 1.12.0 failed.</description>
    </item>
    <item>
      <title>Fix: MCP Servers Dont Work with NVM</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-stdio-server-exits-shell-path-not-inherited.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-stdio-server-exits-shell-path-not-inherited.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: client log: Server transport closed unexpectedly, this is likely due to the process exiting early
Root cause: GUI clients launch MCP servers without sourcing the user's shell config, so the child gets a minimal PATH.
Fix first: Confirm the failure is launch-environment, not a broken server: it runs in your terminal but fails when the client launches it.</description>
    </item>
    <item>
      <title>Fix: SyntaxError in stdio deserializeMessage a console.log in the server triggers it</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-stdio-stdout-logging-breaks-protocol.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-stdio-stdout-logging-breaks-protocol.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: client error SyntaxError: ... is not valid JSON inside deserializeMessage / JSON.parse
Root cause: In the stdio transport, stdout is the JSON-RPC channel.
Fix first: Remove or redirect all stdout writes in the server; use stderr.</description>
    </item>
    <item>
      <title>Fix: When using Streamable HTTP transport, the oauth flow is not triggered when the server returns 401 resolved in a released Inspector version</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-streamable-http-client-no-oauth-on-401.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-streamable-http-client-no-oauth-on-401.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: connecting to an OAuth-protected MCP server over Streamable HTTP hangs
Root cause: The SSE client transport detected a 401 and started authorization.
Fix first: Upgrade to a client/Inspector/SDK version where Streamable HTTP triggers OAuth on 401 (resolved in a released Inspector version).</description>
    </item>
    <item>
      <title>Fix: Time server fails under EDT timezone use --local-timezone with an IANA name</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-time-server-invalid-local-timezone.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-time-server-invalid-local-timezone.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: uvx mcp-server-time traceback through zoneinfo/_common.py load_tzdata failing to load the timezone
Root cause: The server resolves the local timezone, but the platform reports a non-IANA abbreviation (e.g. EDT).
Fix first: Pass an explicit IANA timezone with --local-timezone.</description>
    </item>
    <item>
      <title>Fix: mcp client times out after 60 seconds (ignoring timeout option); comments confirm callTool request options and resetTimeoutOnProgress</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-ts-client-default-60s-request-timeout.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-ts-client-default-60s-request-timeout.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: McpError: MCP error -32001: Request timed out with data: { timeout: 60000 }
Root cause: The default per-request timeout is 60000 ms.
Fix first: Pass request options as the third argument to callTool with a larger timeout and resetTimeoutOnProgress: true.</description>
    </item>
    <item>
      <title>Fix: @modelcontextprotocol/sdk fails in CommonJS projects due to incompatible ESM-only dependency pkce-challenge</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-ts-sdk-commonjs-esm-pkce-challenge.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-ts-sdk-commonjs-esm-pkce-challenge.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: runtime crash on MCP client init: ERR_REQUIRE_ESM: require() of ES Module pkce-challenge is not supported. Use dynamic import() instead
Root cause: pkce-challenge shipped as ESM-only.
Fix first: Upgrade @modelcontextprotocol/sdk to a version that lazily import()s pkce-challenge.</description>
    </item>
    <item>
      <title>Fix: Elicitation feature fails on Cloudflare Workers due to AJV code generation EvalError</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-ts-sdk-edge-runtime-ajv-codegen-evalerror.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-ts-sdk-edge-runtime-ajv-codegen-evalerror.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: EvalError: Code generation from strings disallowed for this context, with a stack through new Function and Ajv.localCompile
Root cause: The SDK validates JSON Schema with AJV v6, which generates validator code at runtime via new Function.
Fix first: On Cloudflare, use the McpAgent integration that added elicitation support; call elicitation on the McpAgent class, not mcpServer.server.</description>
    </item>
    <item>
      <title>Fix: Type instantiation is excessively deep when importing ToolCallback Zod author recommends single Zod version + modern moduleResolution; fixed in Zod 4.1.6</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-ts-sdk-type-instantiation-excessively-deep.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-ts-sdk-type-instantiation-excessively-deep.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: Type instantiation is excessively deep and possibly infinite.ts(2589) on lines referencing SDK tool types
Root cause: Deep generic instantiation in Zod's types as consumed by the SDK's tool typings.
Fix first: Ensure a single Zod version is installed; duplicates are a common trigger.</description>
    </item>
    <item>
      <title>Fix: MCP SDK v1.17.5 Incompatible with Zod v4 - Breaking Changes</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-ts-sdk-zod-v4-incompatible.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-ts-sdk-zod-v4-incompatible.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: tool execution returns {&quot;code&quot;:-32603,&quot;message&quot;:&quot;w._parse is not a function...&quot;}
Root cause: MCP SDK versions up to ~1.17.5 declare zod ^3.x and call Zod internal API (_def, _parse).
Fix first: Quick unblock: pin Zod v3 and ensure a single Zod version resolves.</description>
    </item>
    <item>
      <title>Fix: Windows npx launch failure with garbled 'not recognized' error -32000</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/mcp-windows-npx-requires-cmd-c-wrapper.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/mcp-windows-npx-requires-cmd-c-wrapper.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: Windows only: the MCP server will not start
Root cause: On Windows npx and npm are npx.cmd / npm.cmd batch files, not executables.
Fix first: Launch through cmd: set command to 'cmd' and args to ['/c','npx','-y','&lt;package&gt;', ...].</description>
    </item>
    <item>
      <title>Fix: PortAudio stream stop()/close() on a hotkey-callback thread can freeze the global hotkey listener</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/portaudio-stream-close-blocks-hotkey-callback-thread.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/portaudio-stream-close-blocks-hotkey-callback-thread.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: a push-to-talk dictation daemon intermittently goes unresponsive after switching windows and dictating
Root cause: stop()/close() of a PortAudio stream on a flaky/display-connected device can block for a long time.
Fix first: Move recorder.stop() (the PortAudio stream.stop()/close() calls) AND all downstream processing off the pynput key-release callback thread into a background thread.</description>
    </item>
    <item>
      <title>Fix: pynput Controller.type() scrambles mixed Chinese+English text on macOS; use clipboard paste</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/pynput-mixed-cjk-ascii-type-out-of-order-macos.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/pynput-mixed-cjk-ascii-type-out-of-order-macos.html</guid>
      <pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: injecting '打开Claude Code，然后commit一下。' yields '打开ClaudeC，然后一下。odecomit' — reordered, English fragments shoved to the end, some CJK dropped
Root cause: On macOS pynput types CJK characters via synthesized Unicode events and ASCII via key events.
Fix first: Switch text injection from per-character keyboard.type() to clipboard paste: copy the full string via pbcopy, then simulate Cmd+V.</description>
    </item>
    <item>
      <title>Fix: uv fails in a managed workspace because cache or Python install paths are outside writable roots</title>
      <link>https://laozhangzzz.github.io/agent-pitbook/pits/uv-cache-outside-workspace-sandbox.html</link>
      <guid isPermaLink="true">https://laozhangzzz.github.io/agent-pitbook/pits/uv-cache-outside-workspace-sandbox.html</guid>
      <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
      <description>Problem: uv run or uv sync fails with permission or sandbox filesystem errors
Root cause: uv defaults to cache or interpreter directories outside the agent's writable roots.
Fix first: Set UV_CACHE_DIR to a workspace-local directory.</description>
    </item>
  </channel>
</rss>
