feat: add HttpRequestTool for REST API testing

[LifeJiggy]

Summary

• what changed: Added HttpRequestTool - a new tool for making HTTP requests (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS) to test REST APIs directly from within OpenClaude
• why it changed: Developers often need to test APIs while working in Claude. Instead of switching to terminal/Postman, they can now make HTTP requests directly. Also added setCleanupTimeout helper to cleanupRegistry.ts to fix a memory leak where cleanup callbacks were accumulating.

Impact

• user-facing impact: Users can now make HTTP requests to test REST APIs without leaving Claude. Supports custom headers, query params, request body, and timeout handling.
• developer/maintainer impact: New tool adds to the codebase. The setCleanupTimeout helper prevents memory leaks from accumulated cleanup closures in long-lived sessions.

Testing

• bun run build
• bun run smoke
• focused tests: bun test src/tools/HttpRequestTool/

Notes

• provider/model path tested: N/A (HTTP tool, no LLM provider needed)
• screenshots attached (if UI changed): N/A
• follow-up work or known limitations: Could add response body size limits for very large responses

[jatmn]

Findings

• [P1] Register the HTTP tool so users can actually call it
  src/tools.ts:182
  The PR adds HttpRequestTool, but it never imports it into src/tools.ts or adds it to getAllBaseTools(). That registry is what getTools() uses for the CLI, SDK, default preset, permission filtering, and ToolSearch exposure, so this ships new files and tests but no user-visible HttpRequest tool. Please wire the tool into the base tool list, and decide whether it should be immediately available or deferred like WebFetchTool.

• [P2] Re-save the new TypeScript files as UTF-8 text
  src/tools/HttpRequestTool/HttpRequestTool.ts:1
  The new HttpRequestTool source, test, and prompt files are committed as UTF-16 LE, so Git treats them as binary (git diff --numstat reports - - for all three files and gh pr diff cannot show their contents). That makes the code hard to review in GitHub and can break normal text tooling. Please re-save these files as UTF-8, matching the rest of the repo, before merging.

• [P2] Enforce the response size limit while reading, not after resp.text()
src/tools/HttpRequestTool/HttpRequestTool.ts:83
  The prompt says the response size is limited to prevent memory issues, but the implementation first reads the entire response with await resp.text() and only then truncates to MAX_BODY_CHARS. A large or streaming response can still consume unbounded memory before truncation happens. Please read from resp.body with a cap, abort once the limit is reached, and add a focused test that proves an oversized response is stopped before the full body is buffered.

[gnanam1990]

Thanks for putting this together — a first-class HTTP tool is a genuinely useful addition, and the API surface you've designed reads cleanly.

I went through it independently alongside @jatmn's review, and his points all hold: the tool isn't yet wired into getAllBaseTools() in src/tools.ts (so it can't be invoked yet), the three files landed as UTF-16 LE which makes them render as binary on GitHub, and the response is capped only after the full body is already read into memory via await resp.text().

One more item worth raising before the next pass, since it's the most important one: HttpRequestTool.ts:82 issues a raw fetch() to an arbitrary, agent-supplied URL with arbitrary headers and redirect: 'follow' by default, without any SSRF guard, domain blocklist, or allowlist. We already have WebFetchTool solving exactly this — it routes through ssrfGuardedLookup + checkDomainBlocklist (src/tools/WebFetchTool/utils.ts:18,285) to prevent requests reaching localhost, internal services, or the cloud metadata endpoint (169.254.169.254), and to re-check redirect targets. Could the new tool reuse that same path? The checkPermissions "ask" prompt is helpful interactively but isn't a sufficient safeguard on its own in SDK / non-interactive flows.

No rush — once the registration, encoding, buffering, and the SSRF guard are addressed, I'd be glad to take another look. Appreciate the work here.