Preview links & localhost access

When you ask an agentic worker 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 agentic worker 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 agentic worker 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 agentic worker refuses to publish a link at all rather than expose unreleased work.
• →Not a public link. Every preview URL sits behind that sign-in gate, so pasting it to someone outside your team doesn't grant them access. The preview itself has no login of its own, which is why the gate is enforced for every link.
• →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 agentic worker 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 agentic workers locally. They 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.