9d1dcce441
* chore: reduce output verbosity for local dev and AI agent workflows - Set npm loglevel=warn to suppress install/run progress noise - Switch Playwright local reporter from list to dot (less output per test, CI unchanged) - Add scripts/setup.sh for one-time local git config (compact log, short status) - Document setup script in AGENTS.md Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * chore: remove loglevel=warn and alias suggestions - Revert loglevel=warn from .npmrc — too broad, suppresses CI output - Remove shell alias suggestions from setup.sh — out of scope for a repo script Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * chore: replace setup.sh with command output guidance in AGENTS.md Removes setup.sh in favour of explicit quiet-command guidance that benefits all agents (Claude, Copilot, Codex) without requiring a one-time setup step. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * chore: add cx semantic code navigation guidance to AGENTS.md cx gives agents a cost ladder (overview → symbols → definition → read) that reduces file reads for all agents that read AGENTS.md — complementary to CodeGraph which is Claude Code-specific. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * plan pass 2 * answer questions * add tests * theme tests * more tests * feat: move plugin loading/execution to hidden BrowserWindow (Phase 1) All plugin API calls (getThemes, getPlugins, getActivePlugins, reloadPlugins, getRequestActions, getRequestGroupActions, getWorkspaceActions, getDocumentActions) are now routed through a dedicated hidden BrowserWindow with nodeIntegration:true instead of running directly in the renderer. IPC relay: renderer → ipcMain.handle → plugin window webContents → ipcRenderer.send back to main → resolve renderer promise via pending-request map with 30s timeout. Renderer-side callers updated to use window.main.plugins.* bridge. Two new esbuild entry points added (plugin-window, plugin-window-preload). Dev build threshold updated from 3 to 6 to account for all contexts. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * feedback * feat: route plugin action execution through hidden BrowserWindow bridge Add executeAction IPC method so all four plugin action dropdowns (request, requestGroup, workspace, document) dispatch through the plugin window instead of running context modules directly in the renderer. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * feat: route template tag listing and action execution through plugin bridge Bridge getTemplateTags() and runTemplateTagAction() so code-editor, one-line-editor, and tag-editor no longer import from plugins/index or plugins/context/store in the renderer. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * feat: complete Phase 1 — all plugin execution routed through hidden BrowserWindow Bridge template tags (getTemplateTags, runTemplateTagAction), bundle plugin listing (getBundlePlugins), and elevated plugin actions (executePluginMainAction) so no renderer code calls plugin index or context modules directly for execution. Remaining renderer plugin imports are intentional: applyColorScheme/getColorScheme (DOM utilities) and createPlugin (filesystem scaffolding), neither of which is plugin execution. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * update plan * fix: initialize plugin window services and add Phase 1a E2E test - Create database.plugin-window.ts IPC proxy so the plugin window reads from the main process NeDB connection instead of opening a second one - Initialize database + services in entry.plugin-window.ts before sending plugin-window-ready, fixing the silent "Service not initialized" crash that was masked by unawaited promises - Add isMainWindow fallback to the page fixture so firstWindow() racing to return the hidden plugin window doesn't break other tests - Add plugin-bridge.test.ts: E2E test that writes a requestAction plugin, reloads via the bridge, and verifies the action appears in the request dropdown Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix lint * fix: only send plugin-window-ready after successful initialization Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix assertion * add found * better * fix: stabilize hidden window smoke flows Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * feat: bridge request and response hooks through the plugin window Moves requestHooks and responseHooks execution into the hidden plugin window via the IPC bridge. The default-headers built-in runs in the renderer (no IPC). A cached hasRequestHooks/hasResponseHooks check in the main process avoids any plugin window round-trip per request when no user plugins have hooks registered. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: handle non-renderer processes in plugin hook functions _applyRequestPluginHooks and _applyResponsePluginHooks now use window.main.plugins.* IPC only in the Electron renderer. In the main process (OAuth2 token exchange via get-token.ts) and Node.js CLI (insomnia-inso), they fall back to loading plugins directly via plugins.getRequestHooks/getResponseHooks. This fixes: - inso CLI: "window is not defined" in all run collection/test commands - Electron: OAuth2 token exchange failing with "no access token provided" Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix unit test * fix: increase findMainWindow timeout and skip plugin window by title Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: defer plugin window creation until after main window loads Playwright's firstWindow() was racing with the plugin window and sometimes returning it instead of the main app window. By deferring createPluginWindow() to did-finish-load on the main window, the plugin window is guaranteed to not exist yet when firstWindow() resolves. Removes the findMainWindow polling fallback from the test fixture. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * refactor: replace any[] cast in nunjucks context menu with narrow ContextMenuTag type Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: safely stringify non-Error rejections in response hook error handler Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * feat: bridge plugin UI calls (alert/dialog/prompt/clipboard) from plugin window to main renderer Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix test * docs * add tests and observability * docs * feat: implement invokePluginMethod for plugin communication and add tests * document switch * fix test * fix: move plugin killswitch from preload to renderer to prevent packaged app crash The preload was statically importing invokePluginMethod which pulled the entire plugin system (network stack, NeDB, plugin contexts) into the preload bundle. In production the bundle is built fresh from source, causing a module-level crash before window.main is set — breaking the critical backup smoke test with "Cannot read properties of undefined (reading 'secretStorage')". Move the INSOMNIA_ENABLE_PLUGIN_BRIDGE killswitch into a new renderer-bridge.ts module that lives in the Vite renderer bundle where those deps already exist. The preload now always uses IPC for all plugin calls. All window.main.plugins.* call sites updated to use the bridge. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * chore: eslint autofix import ordering Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Insomnia API Client
Insomnia is an open-source, cross-platform API client for GraphQL, REST, WebSockets, Server-Sent Events (SSE), gRPC and any other HTTP compatible protocol.
With Insomnia you can:
- Debug APIs using the most popular protocols and formats.
- Design APIs using the native OpenAPI editor and visual preview.
- Test APIs using native test suites and collection runner.
- Mock APIs using a cloud or self-hosted mocking server.
- Build CI/CD pipelines using the native Insomnia CLI for linting and testing.
- Collaborate with others using the many collaboration features.
- And more including the ability to use 3rd party plugins.
The following storage options are supported for your Insomnia projects, collections, design specs and all other resources:
- Local Vault: for 100% local storage of collections, design specs and every other resource.
- Git Sync: for Git storage using any 3rd party Git repository, without going through the cloud.
- Cloud Sync: for cloud collaboration, optionally end-to-end encrypted (E2EE) in the cloud.
Get started for free
Insomnia is available for Mac, Windows, and Linux and can be downloaded from the website:
Account & Subscriptions
You can use Insomnia without an account with the local Scratch Pad, or you can create an account for free to get access to the full capabilities of the product.
Even with an account, Insomnia only stores your projects and files accordingly to the storage backend that you have selected, which can be Local Vault, Cloud Sync, Git Sync or any combination of them. As such - for example - you have the freedom to choose to store sensitive projects 100% locally or in a Git repository, while still being able to collaborate on others in the cloud. It's the best of both worlds.
For added security, Insomnia also offers a Private Environments feature, where your environments configuration is always stored locally and never in the cloud, independently from the storage option that you have chosen for your project.
Premium features and support
Insomnia has a very generous free plan that will be satisfactory for most users, but if you need to get access to premium capabilities like unlimited collaboration, the Git Sync feature, the ability to create organizations for your projects, using a 3rd party IDP for logins (SAML, OIDC) and many other features, then you can explore the other subscription plans.
You can compare all subscription plans and get started for free.
Why does Insomnia require an account?
Insomnia does not require an account if you decide to use the local Scratch Pad, but to access most capabilities of the product we require an account. Your account data is securely stored in compliance with ISO27001, SOC 2 Type II, ISO27018, Gold CSA STAR regulations and in accordance with our terms of service and privacy policy.
We require an account to sustainably build and improve the product, and to make sure we can continue to offer the many core capabilities in a free and open-source distribution. While open source software is free to use, it is unfortunately not free to build, and our ability to continue working on Insomnia is dependent on our ability to convert a subset of free users (that need premium features) to become paying customers of our product.
If you are a user that cannot share API data like collections and design specifications to the cloud, this is still possible by selecting "Local Vault" as the storage of your Insomnia projects: having an Insomnia account is not tied to how you wish to store your sensitive API data (which can be stored 100% locally via Local Vault, on a 3rd party Git repository without any cloud storage via Git Sync, or in the cloud for ease of collaboration via Cloud Sync).
Bugs and Feature Requests
Have a bug or a feature request? First, read the issue guidelines and search for existing and closed issues. If your problem or idea is not addressed yet, please open a new issue.
For more generic product questions and feedback, join the Slack Team.
Contributing
Please read through our contributing guidelines and code of conduct. Included are directions for opening issues, coding standards, and notes on development.
Documentation
Check out our official Insomnia Documentation.
Develop Insomnia
Development on Insomnia can be done on Mac, Windows, or Linux as long as you have Node.js and Git. See the .nvmrc file located in the project for the correct Node version.
Initial Dev Setup
This repository is structured as a monorepo and contains many Node.JS packages. Each package has its own set of commands, but the most common commands are available from the root package.json and can be accessed using the npm run … command. Here are the only three commands you should need to start developing on the app.
# Install and Link Dependencies
npm i
# Run Lint
npm run lint
# Run type checking
npm run type-check
# Run Tests
npm test
# Start App with Live Reload
npm run dev
# Start App with both renderer process live reload and main process auto restart
npm run dev:autoRestart
Linux
If you are on Linux, you may need to install the following supporting packages:
Ubuntu/Debian
# Update library
sudo apt-get update
# Install font configuration library & support
sudo apt-get install libfontconfig-dev
Fedora
# Install libcurl for node-libcurl
sudo dnf install libcurl-devel
Also on Linux, if Electron is failing during the install process, run the following
# Clear Electron install conflicts
rm -rf ~/.cache/electron
Windows
If you are on Windows and have problems, you may need to install Windows Build Tools
Editor Requirements
You can use any editor you'd like, but make sure to have support/plugins for the following tools:
- ESLint - For catching syntax problems and common errors
- JSX Syntax - For React components
Develop Inso CLI
npm i- Start the compiler in watch mode:
npm run inso-start - Run:
./packages/insomnia-inso/bin/inso -v
Plugins
Search for, discover, and install plugins from the Insomnia Plugin Hub!
Community Projects
- Insomnia Documenter - Generate beautiful API documentation pages using the documenter plugin or your Insomnia export file.
- GitHub API Spec Importer - A complete set of GitHub REST API route specifications that can be imported straight into Insomnia.
- Swaggymnia - Generate Swagger documentation for your existing API in Insomnia.