Slack CLI `slack run`: pinning a stable tunnel URL across local sessions

Short answer

There is no well-established, documented slack run flag for pinning a stable tunnel hostname, and manifest.yaml does not interpolate .env variables at run time — URL values are written literally when the manifest is created or applied. But for most apps the pinned-hostname problem never arises, because slack run uses Socket Mode for events and interactivity, which is an outbound WebSocket and needs no public URL at all. The only features that genuinely need a stable hostname are HTTP-facing ones, primarily OAuth redirect URIs.

Likely explanation vs. confirmed facts

Confirmed by design: Socket Mode triggers (events, slash commands, interactivity) travel over the CLI's outbound connection, so a random ngrok subdomain cannot break them. Manifests are static definitions applied via Slack's app config APIs; there is no documented runtime variable interpolation.

Likely, but version-sensitive: whether your installed CLI exposes any tunnel configuration (provider, domain, authtoken passthrough). This has changed across releases, so treat it as unverified until you check locally.

What to do, in order

1. Remove absolute local URLs you don't need. If a trigger works over Socket Mode, delete its request URL from the manifest. This alone eliminates the per-session mismatch for everything except OAuth.
2. Check your installed CLI for tunnel options:

   slack --version
   slack run --help

   Look for a flag related to tunneling, domain, or hostname. If none exists in your version, the CLI does not support pinning — full stop.
3. For OAuth, use one stable URL. The documented-pattern fallback is to point the manifest's redirect URI at a stable hostname you control: either an ngrok static domain (an ngrok account/plan feature, not a Slack CLI feature — verify your plan offers one) or a cheap deployed/staging endpoint that proxies to local during development.
4. Or re-apply the manifest per session. Capture the assigned tunnel hostname at session start, rewrite the redirect/request URLs, and update the app config programmatically (via the CLI's manifest command or the apps.manifest.update API). Script it; never hand-edit, and never commit a random hostname or .env secrets into the shared manifest.

Cautions

• ngrok free tier historically assigns random subdomains per session; plan features change, so verify rather than assume.
• Don't enable both Socket Mode and HTTP request URLs for the same feature — you can get duplicate or missed deliveries.
• Manifest edits are app-config changes visible to every collaborator on the app.

Exact flags and tunnel behavior vary by CLI release; this reflects well-established behavior as of recent v2.x versions. Confirm against your installed version's help output before scripting around it.