Apps reach their dens from every window — even the native shell

[jerpint]

The pond went dark for the apps

Somewhere along the unified-navigation trail, the dens lost their doorways. Clicking a running app used to open its own space at blog.localhost:7777 — a real origin, root and all. The navigation rework swapped that for the path route /app/{name}/, and the lodge, trying to be helpful, redirected clicks to the app's raw in-container port (localhost:4001). But that port is never published to the host — only 7777 is. So the redirect was a dead end everywhere except a browser that happened to expose the port. In the macOS shell it was worse: the redirect pointed at the public tunnel, or nowhere.

The colony has exactly one way apps were ever meant to be reached: the subdomain_proxy middleware, which takes blog.localhost:7777 (or blog.woltspace.com through the tunnel) and forwards it — inside the container — to the app's port. One doorway (7777 / the tunnel), fan-out by hostname. That keeps every app at the root of its own origin, so absolute paths, cookies, and routing behave the same in or out of woltspace.

This PR points every client back at that doorway, and teaches the native shell to walk through it.

What changed

• server/app.py — apps redirect to their own origin, never a raw port. /app/{name}/ now redirects to the app subdomain: {name}.localhost:<lodge-port> locally, {name}.{tunnel} publicly — which the existing subdomain_proxy forwards to the in-container port. The raw-port redirect is gone; it was a dead end for every client but a lucky same-host browser. Also fixes is_local, which never matched 127.0.0.1 — exactly the origin the desktop shell loads from.
• desktop/src-tauri/Info.plist — ATS exception for localhost + subdomains. macOS App Transport Security waves through 127.0.0.1 and the literal localhost (how the shell reaches the lodge), but not *.localhost. So WebKit silently refused to follow the lodge's redirect to an app and the window never moved. The exception lets the shell take the same path a browser does. Tunnel app subdomains are HTTPS and need nothing.

Together: apps behave identically in a browser, the PWA, the desktop shell, and through the Cloudflare tunnel.

Why it's shippable, not a per-user hack

• The redirect fix rides inside the Docker image — every rebuild/update carries it.
• The ATS exception is compiled into the .app bundle — every install carries it.
• No per-machine settings, no manual steps. (Local unsigned iteration still needs a quarantine strip; a notarized release doesn't.)

Test plan

• /app/blog/ → 302 → http://blog.localhost:7777/ (was → localhost:4001); path + query preserved
• Host: blog.localhost:7777 still serves the app 200 (proxy path intact)
• Loads in a browser at localhost:7777
• Loads through the Cloudflare tunnel (blog.<domain>)
• ATS key verified present in the bundled Info.plist
• Loads in the rebuilt desktop shell — click → app renders in-window
• bash test/run-tests.sh unit on CI

One-line closer

🦫 the dens have doorways again — and the native shell finally knows how to knock.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
woltspace	Ready	Preview, Comment	Jul 23, 2026 10:33pm