Preview links & localhost access

When you ask an agent to run a feature, it starts your app's services on our infrastructure and exposes them at a private, sign-in-protected preview URL. There are two ways to reach that running app — both hit the same remote services behind the same access gate:

1. →In your browser (primary). Open the URL, sign in with your team's Slack workspace, and you're looking at the live app.
2. →From your localhost (optional). Forward a local port to the remote service with pomerium-cli, so you can point local tools — or another local component — at the running app.

The agent posts the exact link and any forwarding commands into your chat when the app is ready.

Browser access

Ask in plain English, right in chat:

"Spin up the checkout feature and give me a private test link."

The agent runs the app's services in an isolated sandbox, exposes them through our preview gateway, and puts a sign-in gate in front. You get a URL like https://<your-session>.svc.awkteams.ai. Open it, choose Sign in with Slack, approve with your team's Slack workspace, and you're in. One login covers the whole app — the front-end, the API, and any websockets are routed under that single URL.

  Ask in chat  ──▶  Get a link  ──▶  Sign in with Slack  ──▶  You're in

• →Private by default. Only people from your team — your approved Slack identities and your company's approved email domains — can get in. The gate is enforced on our side and is not optional: if no allowed identities are configured, the agent refuses to publish a link at all rather than expose unreleased work. The sign-in gate is the only authentication layer in front of these services, so it is never skipped.
• →No public link. A preview URL is never open to the internet — it always sits behind the sign-in gate, so pasting it to someone outside your team doesn't grant them access.
• →Sessions last 24 hours, then you re-authenticate.
• →No setup, no infrastructure to build. Nobody is pulled off their work, and nothing is left running afterwards — the preview is cleaned up when you're done, so there's no standing cost.

Localhost access (optional)

Sometimes you don't want a browser tab — you want the remote service reachable at a localhost:PORT on your own machine. For example:

• →Running a local front-end against the remotely-spawned back-end
• →Pointing a local tool, script, or test suite at the running service
• →Reaching a service that isn't plain HTTP (a database, a TCP API)
• →Working with a multi-service app, where each service is forwarded to its own local port

This forwards your local port to the remote service — the service still runs on our infrastructure; you're just tunnelling to it.

Prerequisite

The pomerium-cli installed on your machine. You do not need your own account with any identity provider — you sign in with your team's Slack workspace, and the access gate runs on our side.

macOS (Homebrew): brew install pomerium/tap/pomerium-cli

Linux / Windows: download pomerium-cli from the Pomerium CLI releases page, or follow the instructions in the Pomerium docs.

Forward a port

The agent gives you the exact command per service. It looks like this:

pomerium-cli tcp <your-session>.tcp.svc.awkteams.ai:8080 \
  --listen 127.0.0.1:8080

The local port matches the app's port — forward :8080 to 127.0.0.1:8080 — so the service ends up on the same localhost:8080 you'd expect. Run the command and the remote service is reachable at http://localhost:8080. The first connection opens your browser once for the same Sign in with Slack login as the browser flow — the gate applies here too. For a multi-service app, run one command per service, each on its own local port; everything ends up on your localhost.

If :8080 is already in use locally, the :8080 after --listen is just a convenient default — swap in any free port (e.g. --listen 127.0.0.1:9090, then browse http://localhost:9090). Keep the remote <your-session>.tcp.svc.awkteams.ai:8080 as-is: that one must match the app's actual port.

Limitations

• →You cannot run the full agent mesh locally. Agents always run on our hosted infrastructure; localhost access only tunnels you to the services they've already started.
• →The link is tied to the running preview. When the preview is cleaned up, the URL and the forwards stop working.
• →Latency may be higher than running everything locally, due to the extra hop through the preview gateway.