macOS Tahoe 26.3.1: Local Network permission lost after update (localhost blocked)

[DeployIsComing]

Expected Behavior

Expected behavior

Insomnia should either keep the existing Local Network permission after update or properly request it again when trying to access localhost.

Actual behavior

The permission is lost silently and never requested again. Access to localhost is blocked by macOS.

Environment

• macOS version: 26.3.1 (build 25D771280a) — macOS Tahoe
• Insomnia version: [insira aqui a versão exata que você está usando]
• Installation method: Downloaded from insomnia.rest (not App Store)

Thanks!

Actual Behavior

Describe the bug

After updating Insomnia, the app disappears from the Privacy & Security → Local Network list in macOS.

As a result, Insomnia can no longer connect to any localhost server (http://localhost:xxxx or http://127.0.0.1:xxxx). The connection simply fails (timeout / connection refused), and no permission prompt appears.

This started happening after an update and persists even after:

• Reinstalling Insomnia (clean install, removing all folders in ~/Library/)
• Running tccutil reset LocalNetwork
• Resetting the network extension plist in Recovery Mode
• Restarting the Mac multiple times

Reproduction Steps

Steps to reproduce

1. Have Insomnia working with Local Network permission granted.
2. Update Insomnia (via auto-update or manual download).
3. Try to send a request to any local server (localhost or 127.0.0.1).
4. Check System Settings → Privacy & Security → Local Network → Insomnia is gone or the toggle does nothing.

Is there an existing issue for this?

• I have searched the issue tracker for this problem.

Which sync method do you use?

• Git sync.
• Insomnia Cloud sync.
• Local only

Additional Information

Additional context

This seems to be a recurring macOS issue (Sequoia + Tahoe) with Electron apps, where code signature or bundle changes cause the Local Network entitlement to be treated as a new app. Many users are affected, but it is especially painful for API development tools like Insomnia that heavily rely on local backends.

Workarounds tried (all failed):

• Using [::1] instead of localhost
• Resetting TCC database
• Full clean reinstall + Recovery Mode plist removal

Would appreciate any guidance on how Insomnia can better handle macOS Local Network permission persistence across updates.

Version: Insomnia 12.5.0
Build date: 4/1/2026
OS: Darwin arm64 25.3.0
Electron: 41.0.3
Node: 24.14.0
Node ABI: 145

Insomnia Version

12.5.0

What operating system are you using?

macOS

Operating System Version

Tahoe 26.3.1 (a)

Installation method

download

Last Known Working Insomnia version

No response

[ryan-willis]

@DeployIsComing thank you for the report, we're seeing similar cases for this specific version of macOS.

If possible, does upgrading to the latest Tahoe release, 26.4, resolve this issue?

I've opened a PR that will prompt for local network access: #9784

[ryan-willis]

For posterity, the real issue here was a regression in one of Insomnia's core dependencies, node-libcurl@3.2.1. It was built without support for IPv6, which prior to that release was assumed to be enabled by default. When built with support for IPv6, it will attempt connections on both stacks and pick the first successful connection.

On macOS, when explicitly listening on localhost (with NodeJS at least), the listener is bound exclusively to the IPv6 loopback (::1). Prior versions of Insomnia would attempt both stacks and succeed with IPv6:

The next release of Insomnia (v12.6.0, in beta soon) will be built using the fixed version (node-libcurl@3.2.2, released today)