Request history for .http files

All four run the same plain-text .http format, but history isn't part of that format. Each tool bolts it on its own way, with different limits. Facts below are as of August 2026.

VS Code REST Client

Press Ctrl+Alt+H, or run Rest Client: Request History from the command palette. You get the last 50 requests, newest first. The request details (method, URL, headers, and body) are persisted to a file, so the list survives closing VS Code, and Rest Client: Clear Request History empties it. Pick an entry and it opens in a temp file, ready to send again.

What you get back is the request. The response it produced at the time isn't stored next to it, so history will re-send the call rather than show you the body you're trying to remember.

JetBrains IDEs (IntelliJ IDEA, Rider, WebStorm)

Tools | HTTP Client | Show HTTP Requests History opens http-requests-log.http, which lives under the .idea/httpRequests/ directory of the current project. The IDE saves the 50 most recently executed requests there and writes each response into a separate file in the same directory, so unlike the REST Client, the response bodies are on disk.

The path is the catch. .idea/ is per project, so switching repository switches history. If you touch several services in a day, your record of what you called is split across as many folders as you opened. Check that directory is in your .gitignore, too, for the reason covered under credentials below.

Visual Studio 2022

There isn't any. Microsoft's documentation lists Request history among the features the Visual Studio 2022 .http editor doesn't have and that exist only in the VS Code extension. Send a request, close the response pane, and it's gone. See the Visual Studio .http guide for what it does do well.

Karve

A local SQLite database, 5,000 entries, request and full response, searchable, spanning every file in the workspace rather than one project. Details in the next section.

The history features above run into the same three limits, and each one bites at a different moment:

• Depth. Fifty entries sounds generous until a debugging session with a loop of retries eats thirty of them before lunch. The call you want to compare against is from Tuesday.
• Scope. History that lives in .idea/ or in one editor's state is tied to the project you had open. The request that mattered was in the payments repo, and you're in the gateway repo now.
• Content. Re-running a request tells you what the endpoint does today. "It gave me a 403 yesterday" is only useful if yesterday's 403 body, with its error code, is still somewhere you can read it.

None of this makes those tools bad. They're editors, and history is a side feature there. It's worth knowing which of the three limits you're relying on before you need it.

Karve records every successful send, the request and the full response, into a SQLite database in its local application data folder. Nothing is uploaded; the history file sits on your PC like the .http files themselves.

One honest edge: transport failures and cancelled sends show up in the response viewer, but they are not written to history. A request that never reached a server leaves no entry.

• Retention. The newest 5,000 entries are kept. Response bodies over 1 MB keep their metadata (method, URL, status, timing, size) but the body itself isn't stored.
• Search. One box — Ctrl+Shift+F — searches your history alongside your request files. Past runs are matched on method, URL, status code, and file path: type 500 to find the failures, or a path fragment to find a service. Stored request and response bodies are deliberately not searched — those rows hold the resolved headers and bodies, which is where your tokens are.
• The same box searches your files. Request names, methods, URLs, headers, and bodies are all matched in your .http files, along with file and folder names, and every result tells you why it matched. Files are read exactly as you wrote them, so {{tokens}} stay placeholders and no resolved secret reaches a result row.
• Re-opening a response. Double-click a row and the stored response loads into a tab with a "From history" badge, so you're reading what actually came back. If the source .http file has since moved or been deleted, Karve opens a new tab seeded with the runnable request text instead.
• Workspace-wide. Because a Karve workspace gathers files from across your repos, the history spans them too: one searchable list covering every service you called today.

Comparing two responses side by side isn't shipping yet. Full bodies are retained so diffing can be added without losing what's already stored. See the roadmap.

This applies to every tool on this page. History stores resolved requests: the URL, headers, and body as actually sent, after {{variables}} were substituted. That is where bearer tokens and API keys live. Treat a history file as being as sensitive as the secrets it replayed.

• Keep the real values in environment files, never in the committed request — the environments guide and the auth guide cover the habit.
• In JetBrains IDEs, confirm .idea/httpRequests/ isn't being committed — the log and its response files are inside the project directory.
• In VS Code, Rest Client: Clear Request History exists for exactly this reason. Use it after working against production.
• Karve's history is deliberately not exposed to AI agents over its MCP server. An agent can see that a request references a token; it cannot read the stored record where that token was resolved.