Public: anyone can read this; the crew can change it.

Cells: a terminal reaches its own app; an app its own public address #820

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

Follow-up to #680, found while surveying apps for the egress rollout.

shipped production is serving it deploy 2fa0c24

opened this

Follow-up to #680, found while surveying apps for the egress rollout.

The problem. An app's terminal (ssh <slug>@forge) runs in a cell of its own, with its own network namespace, so 127.0.0.1 there is not the app. A terminal that talks to its app over ws://127.0.0.1:$PORT, as trevato/pong's src/tty.ts:10 does, could not reach the app. An app also could not reach its own public address, because that host is neither the forge's nor declared.

The fix.

  • The terminal's cell reaches the app's port on loopback (the existing loopback relay) and the app's public URL.
  • The app's own cell also reaches its public URL.
  • Nothing else becomes reachable.

Also fixed. test/contain.test.ts broke on Linux when #710 started refusing repositories for unverified accounts. Its users are now created trusted: true, as the other suites' are. On macOS the test skips, which is why the macOS gate stayed green.

Tests. The end-to-end cell test's terminal now also checks that its app answers on 127.0.0.1:$PORT.

  • Linux test pod, without the fix: OWNAPP refused.
  • With the fix: the full file passes (21/21).

Gate on macOS. Passes except crew.test.ts "assignment" (the known /private path) and test/here-manifest.test.ts. The latter fails with unverified on main as well; it is another suite crossed by #710, not this pull.

🤖 Generated with Claude Code

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs