Closing the main window silently stops the proxy listener (port 9090 unbinds) while the app still reports the proxy as running

[anggrayudi]

Description

Closing the main window (⌘W / red button) tears down the proxy listener on port 9090. The app keeps running — it still owns the menu bar and the Dock icon — and it still reports the proxy as active, but nothing is bound to the port anymore. Every client pointed at the proxy fails with Connection refused, with no visible indication that Proxyman stopped proxying.

The silent part is what makes this expensive. An Android emulator with a global HTTP proxy, or a Gradle build resolving dependencies through the proxy, just fails, and the obvious suspects (VPN, DNS, certificates, the emulator's network stack) all look fine. Proxyman itself looks fine too.

Environment

• Proxyman 6.14.0 (61400)
• macOS 26.5.1 (25F80), Apple Silicon (arm64)

Steps to reproduce

1. Launch Proxyman. Confirm the listener is up:
   lsof -nP -iTCP:9090 -sTCP:LISTEN → shows Proxyman ... TCP *:9090 (LISTEN)
curl -x http://127.0.0.1:9090 http://example.com/ → HTTP 200
2. Close the main window with ⌘W. Do not quit — the app stays running and the menu bar still reads "Proxyman".
3. Check again:
   lsof -nP -iTCP:9090 -sTCP:LISTEN → nothing
   curl -x http://127.0.0.1:9090 http://example.com/ → Connection refused

One caveat on how we got here, so you can weigh the evidence: we could not script ⌘W (System Events needs Accessibility permission, and Proxyman exposes no AppleScript window dictionary — count windows returns error -1708). So step 2 is what we observed happening, from the log below plus a screenshot showing Proxyman owning the menu bar with zero windows on screen while the port was unbound. Steps 1 and 3, and everything under "What we ruled out", were run directly.

While the window is open the listener is stable — sampled every 10–30s across several minutes in two separate runs, always bound and serving.

Expected

Either the proxy keeps running while the app is running, or Proxyman clearly surfaces that closing the window stops proxying.

Actual

The listener is gone, and nothing indicates it. The MCP get_proxy_status still returns Recording: Active / Proxy Port: 9090 / SSL Proxying: Enabled in this state, which is what sent us down the wrong path for a while.

Workaround

Recreating the window brings the listener straight back, no restart needed and the captured session survives:

osascript -e 'tell application "Proxyman" to reopen'

Clicking the Dock icon does the same thing.

What we ruled out

• Being in the background / occluded is fine. Verified bound and serving HTTP 200 with Proxyman sitting behind another app's full-screen window. Only window destruction matters.
• Bringing the app forward is not enough. tell application "Proxyman" to activate leaves it unbound, because it does not recreate a window. Only reopen does. That pair is what isolates the window itself as the trigger.
• Not power or thermal pressure. Low Power Mode off (pmset -g → powermode 0), on AC power at 100%, and pmset -g therm reports no thermal or performance warning recorded.
• Not a crash. The process stays alive throughout and no crash report is generated.

Log at the moment it happens

14:35:38  Proxyman  (RunningBoardServices) didChangeInheritances
14:35:38  Proxyman  [com.apple.WebKit:ActivityState] PageClientImpl isViewVisible():
                    viewWindow 0x0, window visible 0, view hidden 0, window occluded 1
14:35:46  port no longer bound

viewWindow 0x0 — no window at all, rather than a merely hidden one.

Possibly related

#1170 (running Proxyman in the background via the menu bar) is the feature request for the state this bug leaves the app in. Even if running windowless is out of scope, the silent teardown seems worth fixing on its own.