NullClaw
NullClaw exposes pairing and MCP lock liveness gaps
NullClaw users report a pairing code that is neither shown nor persisted and MCP stdio calls that can wait indefinitely behind a Proxmox launcher lock; a related request makes Firecrawl search endpoints configurable.
nullclaw/nullclaw issue #993 is the inspected primary source: “feat: make Firecrawl search endpoint configurable for self-hosted instances.” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- nullclaw/nullclaw issue #993 was created 2026-08-24T08:23:37Z and was open at inspection; its title is “feat: make Firecrawl search endpoint configurable for self-hosted instances.” - nullclaw/nullclaw issue #992 was created 2026-08-24T08:11:58Z and was open at inspection; its title is “if the pairing code is hidden, and not written to disk, how can we see it?.” - nullclaw/nullclaw issue #991 was created 2026-08-23T07:23:36Z and was open at inspection; its title is “MCP stdio calls can hang indefinitely behind the Proxmox launcher lock.” - The repository reported 8047 stars, 91 open issues, default branch main, and last push 2026-07-19T04:20:06Z. - The latest tagged-release baseline checked was v2026.5.29 published 2026-05-29T13:41:10Z.
What changed
nullclaw/nullclaw issue #993 reports: Description The built-in Firecrawl search provider in src/tools/web_search_providers/firecrawl.zig has the API endpoint hardcoded: const endpoint = "https://api.firecrawl.dev/v1/search"; This means self-hosted Firecrawl instances cannot be used with the native search_provider: "firecrawl" config — only the hosted api.firecrawl.dev works. Current behavior** search_provider: "firecrawl" always hits https://api.firecrawl.dev/v1/search No config key or env var exists to override the base URL The only workaround for self-hosted Firecrawl is wiring it as an MCP server, which works but loses the simplicity of the built-in provider and doesn't integrate with search_fallback_providers Expected behavior** The Firecrawl provider should respect a configurable base URL, consistent with how search_base_url already works for SearXNG. Two options (not mutually exclusive): 1. Env var: FIRECRAWL_BASE_URL or FIRECRAWL_API_URL (the latter matches the Firecrawl MCP server convention) 2. Config key: something like http_request.firecrawl_base_url, or reuse search_base_url when search_provider is firecrawl Motivation Firecrawl is open source and self-hostable — many operators run it locally for privacy, cost, or latency reasons Other search providers (SearXNG) already support custom endpoints via search_base_url The MCP workaround is functional but doesn't participate in search_fallback_providers chains, so you can't use self-hosted Firecrawl as a fallback alongside other built-in providers This is a ~5-line change in a single file
nullclaw/nullclaw issue #992 reports: Description i've been confused about this issue for the past few days, but i've been trying to configure the gateway API, but couldn't figure out how to get the 6digit pairing token. after looking into it, turns out #535 stopped logging the token to stdout, so now it only exists in memory, and i'm not dedicated enough to try and make sense of a memory page. Expected behavior If another method exists to be able read that token, it would be a good idea to record it in the docs. if logging to stdout was the only option (without setting up a full web server), then maybe consider adding back some way to make it visible by the user. Steps to reproduce do the onboarding, set up a channel (in my case, matrix) then try to get the gateway to work Version v2026.5.29 OS Linux
nullclaw/nullclaw issue #991 reports: Summary A standalone nullclaw agent invocation can hang indefinitely when the configured stdio MCP server is already owned by the long-lived gateway. Reproduction Environment: Proxmox CT 151, NullClaw 2026.8.22, read-only Proxmox MCP bridge (148 tools). 1. Start nullclaw-gateway.service. 2. Run nullclaw agent --agent proxmox-admin -m "Reply with exactly OK and do not use tools.". 3. The CLI agent initializes configured MCP tools before processing the prompt. 4. The Proxmox launcher runs flock /run/lock/proxmox-mcp.lock ssh.... 5. The gateway already holds that lock, so the CLI child waits in flock. 6. NullClaw stdio MCP readLine() has no deadline; the configured/default MCP timeout is not applied to stdio reads. 7. The observed process remains blocked until the external launcher timeout (300s), with no LLM response. Direct authenticated ClawProxy HTTP from the same CT returned HTTP 200 with OK, so the upstream model route was healthy. Evidence CT gateway remained active with NRestarts=0 and /health 200. Hung process tree showed nullclaw agent -> timeout -> flock -> ssh. The MCP server in CT 153 was healthy and reported 148 tools. Source review: McpServer.sendRequest() uses blocking stdio readLine(); timeout handling is implemented for HTTP/curl transport but not stdio transport. The launcher uses a global blocking lock, causing queued duplicate MCP processes. Proposed fix Apply a real deadline to stdio MCP reads for initialize, tools/list,
Why it matters
A secure pairing secret still needs a bounded disclosure path, and a launcher lock needs a timeout or it becomes invisible permanent custody. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.
Current
The primary record was open when captured on 2026-08-25. The tagged-release baseline was v2026.5.29 published 2026-05-29T13:41:10Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/nullclaw/nullclaw/issues/993. Supporting records are https://github.com/nullclaw/nullclaw/issues/992 and https://github.com/nullclaw/nullclaw/issues/991. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Show pairing codes once through an authorized surface, bound launcher-lock waits, and validate configurable search endpoints without weakening SSRF policy. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.