👋 Thanks for opening your first issue! If you're reporting a 🐞 bug, please make sure
you include steps to reproduce it. If you're requesting a feature 🎁, please provide real
use cases that would benefit. 👪

To help make this a smooth process, please be sure you have first read the
contributing guidelines.

I just want to mention here first that you can write a request hook plugin that calls the settingSendCookies(false) method based on the URL of the current request: https://support.insomnia.rest/article/26-plugins#request-hook-api

Personally, if we are to add this as a first-party feature, I feel like a global toggle doesn't make much sense. Rather, a host-based toggle would probably be more appropriate.

A host-based configuration would fit perfectly.

What about the configuration to enable cookies be opt-in instead of opt-out? Insomnia's default behavior would be "no cookies at all". If the user need cookies for some host, then the user must add it to the "hosts with cookies" configuration.

This dialog could have 2 sessions:

1º session: A grid to add hosts that allow cookies to be stored and sent.
2º session: List of stored cookies received by Insomnia (the current behavior).

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Rebooting this with a suggestion: A global (or per-environment or per-collection) preference for the default state of the per-request store/send cookies checkboxes (upon creating a new request) would be a massive quality-of-life improvement. Something like this interface:

Default Settings for New Requests
[√] Send cookies automatically
[√] Store cookies automatically

As an example use case, we often work with vaguely-documented legacy systems and APIs that change behavior based on cookie session state. We use Insomnia to explore how they work and share results with Insomnia Sync, but we need each request we make to start from the fresh and deterministic slate it would when running from our automation workers: defined explicitly by body/auth/query/headers etc., not cookie state that might change nondeterministically based on whether we've already tried the request before! It's a massive foot-gun that new requests start off with persistent cookie settings, and perhaps the largest annoyance that Insomnia presents right now!