Thunder Client: a VS Code REST API client that keeps requests on your disk

The problem Thunder Client solves inside VS Code

Testing an HTTP endpoint usually means leaving the editor: open a separate client, rebuild the request, copy the response back. Thunder Client puts that loop in the VS Code sidebar. The README describes it as a lightweight REST API client for VS Code and JetBrains, built around simplicity, clean design and local storage. The intended user is a developer who already has the code open and wants to fire a request at a local or staging endpoint without a second application running. The repository itself is a support repository: the top-level entries are .github/, .gitignore, LICENSE.txt, README.md, docs/, images/ and third-party/. That is where issues and documentation live, not where the extension source is published.

How local storage and environment variables fit together

The mechanism the README commits to is local storage: the extension saves all data on the user's device. Requests live in collections, and collections can reference environment variables, so a base URL or token can be swapped between staging and production without editing each request. Scriptless Testing is the other design decision worth noting. Instead of writing JavaScript assertions the way many API clients expect, the README describes a GUI-based interface for checking responses. For people who do not want test code in their request files, that removes a layer. It also removes the flexibility of arbitrary assertion logic, which is the trade you are making. Git Sync is how the local-first model reaches a team: request data is saved into your Git repository rather than synced through a vendor account. That keeps the data in a place you already control, and it makes request changes reviewable in pull requests. It also means merge conflicts on request files are now your problem, and the README does not describe a conflict-resolution workflow.

Installing the extension and sending a first request

The README gives a short path. Install the extension, click the Thunder Client icon on the Action Bar, then click New Request from the sidebar. The Marketplace listing is the install source for VS Code; JetBrains users install from the JetBrains Marketplace plugin page. The README also points to a walkthrough video at youtube.com/watch?v=NKZ0ahNbmak for the same flow.

After installation, the Thunder Client icon appears on the Activity Bar. Open the sidebar and click New Request. You get a request pane with a method selector, a URL field and tabs for headers, body and tests. Enter a URL such as your local development server, choose GET, and send. The response appears in the pane below with status, headers and body.

For repeatable runs outside the editor, the README describes an advanced CLI that runs requests, collections and cURL commands from the terminal, published on npm as @thunderclient/cli. The README does not list the individual CLI flags, so check the documentation site before scripting it into CI.

Where Thunder Client is the wrong choice

Local storage is the feature and the limitation. If a request collection is meant to be the shared source of truth for a team, the README's answer is Git Sync, which pushes that responsibility onto your repository and your review process. There is no hosted workspace described in the README, so anyone expecting server-side roles, audit logs or a browser-accessible collection will not find them here. The second constraint is the host. Thunder Client runs as an extension inside VS Code or JetBrains. If your workflow involves a terminal-only environment, a headless CI runner without the IDE, or a colleague who does not use either editor, the extension is not the delivery mechanism. The CLI covers part of that gap, but the README treats it as a companion to the extension rather than a replacement for it. The third constraint is testing depth. Scriptless Testing is deliberately GUI-based; teams that need conditional logic, loops or custom assertion libraries in their test definitions should check the documentation before assuming it fits.

Thunder Client versus Postman

The comparison people search for is Thunder Client VS Postman, and the difference is architectural rather than cosmetic. Postman is a standalone application with a cloud account model at its centre: collections sync to a workspace, and collaboration happens through that service. Thunder Client starts from the opposite assumption. It is an extension inside the editor, and the README states that all data is saved locally on the user's device, with Git Sync as the way to share. The practical consequence is where your request data lives and who can reach it. With Thunder Client, that is your filesystem and your Git remote. With Postman, it is a hosted workspace with its own access model. Neither is universally better. A solo developer or a small team already using Git will find Thunder Client's model simpler and closer to how the rest of the code is managed. A larger organisation that needs centralised permissions and a browser-based view of collections is choosing a different set of trade-offs, and the README does not claim Thunder Client covers them.

Release cadence, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-13, the same date as the v2.41.3 release. The two preceding releases are v2.41.0 on 2026-06-25 and v2.40.15 on 2026-06-06, so the recent pattern is a steady stream of patch and minor versions rather than long gaps. For an extension, that cadence is normal and mostly painless: VS Code updates extensions automatically, and the upgrade cost is usually the time to re-check that your collections and environment variables still load. The real cost sits in the CLI, which is published separately on npm as @thunderclient/cli. If you pin it in a CI pipeline, you own the version bumps and the changelog reading yourself.

The licence file is LICENSE.txt at the repository root, and the repository metadata reports the licence as NOASSERTION, meaning GitHub could not map the file to a recognised identifier. The README does not restate the licence terms. If you are evaluating Thunder Client for commercial use, read LICENSE.txt directly and, where the terms are unclear, get your own advice rather than assuming an open source licence applies.

Editorial conclusion

Adopt Thunder Client if you work inside VS Code or JetBrains and want request data to stay on your own machine, with Git Sync as the collaboration path. Do not adopt it if your team needs a hosted workspace with server-side access control, or if you need a client that runs outside an IDE. Before committing, verify that the licence in LICENSE.txt matches how your organisation intends to use the extension and the CLI, and confirm the current release on the VS Code Marketplace matches the version you intend to pin.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. thunderclient/thunder-client-support on GitHub