Uninstall and Disconnect in one environment affect every environment that shares the Slack app #36

New Issue

2026-11-11T11:18:00Z

james.maes commented

2026-11-11 11:18:00 +00:00

Problem

A host can run several environments (for GG Forge: dev, staging and production) against one Slack app in one Slack workspace. Each environment keeps its own workspace and connection records in its own database, so inside the application they look independent. Slack sees a single installed app.

Uninstall (process UNINSTALL on the Workspaces table, SlackProcesses.java:105) calls Slack apps.uninstall (SlackClient.java:152). That removes the app from the Slack workspace, which cuts off every environment that installed the same app, not only the one where the button was pressed.
Disconnect (SlackPreferencesProvider.java:80) calls auth.revoke (SlackClient.java:144) for the user's token. If Slack issued the same user token to the other environments, their connection for that user stops working too.

So an administrator of a development or staging environment can take Slack away from production with one click, and nothing on the screen says so.

How this is known: read from the code at develop and from Slack's documentation. It has not been tried against Slack.

What we would like

Uninstall should say plainly what it does before it runs: that it removes the app from the Slack workspace for every environment and application that uses this Slack app. A confirmation step that names the workspace.
A separate, safe action for the common case: "Forget this installation here". It deletes this environment's stored tokens and records and does not call apps.uninstall.
The same for Disconnect: an option to drop the local connection without auth.revoke, or a clear statement that other environments are affected.
Its own permission for the destructive Uninstall (today it shares the workspace administration permission), so a host can withhold it outside production.
Optional: a host setting sharedApp (or similar) that hides or refuses apps.uninstall in environments that are not the owner of the Slack app.
Documentation: a section on running several environments against one Slack app, including that events and interactivity have a single request URL per app.

Until then

Hosts with one shared Slack app should treat Uninstall in any environment as a production action and limit who holds Slack administration in the non-production environments.

Raised by James Maes on 2026-11-10 while setting up GG Forge production.

## Problem A host can run several environments (for GG Forge: dev, staging and production) against one Slack app in one Slack workspace. Each environment keeps its own workspace and connection records in its own database, so inside the application they look independent. Slack sees a single installed app. - **Uninstall** (process `UNINSTALL` on the Workspaces table, `SlackProcesses.java:105`) calls Slack `apps.uninstall` (`SlackClient.java:152`). That removes the app from the Slack workspace, which cuts off every environment that installed the same app, not only the one where the button was pressed. - **Disconnect** (`SlackPreferencesProvider.java:80`) calls `auth.revoke` (`SlackClient.java:144`) for the user's token. If Slack issued the same user token to the other environments, their connection for that user stops working too. So an administrator of a development or staging environment can take Slack away from production with one click, and nothing on the screen says so. How this is known: read from the code at `develop` and from Slack's documentation. It has not been tried against Slack. ## What we would like 1. Uninstall should say plainly what it does before it runs: that it removes the app from the Slack workspace for every environment and application that uses this Slack app. A confirmation step that names the workspace. 2. A separate, safe action for the common case: "Forget this installation here". It deletes this environment's stored tokens and records and does not call `apps.uninstall`. 3. The same for Disconnect: an option to drop the local connection without `auth.revoke`, or a clear statement that other environments are affected. 4. Its own permission for the destructive Uninstall (today it shares the workspace administration permission), so a host can withhold it outside production. 5. Optional: a host setting `sharedApp` (or similar) that hides or refuses `apps.uninstall` in environments that are not the owner of the Slack app. 6. Documentation: a section on running several environments against one Slack app, including that events and interactivity have a single request URL per app. ## Until then Hosts with one shared Slack app should treat Uninstall in any environment as a production action and limit who holds Slack administration in the non-production environments. Raised by James Maes on 2026-11-10 while setting up GG Forge production.

james.maes added the enhancement label 2026-11-11 11:18:00 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QRun-IO/qbit-slack#36