Repository navigation
Enterprise App Token Support #5
Description
Activity
hmm, that's quite a thing! I am wondering how Slack Enterprise knows that a non-official client is in use. Regarding an official slack app - are you able to install Slack apps? if so, then that might be a viable option.
Unsure if I personally can install apps into our instance but probably not. But we do have many apps installed.
https://github.com/rneatherway/gh-slack fetches the enterprise token from the app bundle's cookie jar using a decryption key fetched from the keychain on MacOS, maybe there's some secret sauce there?
I don't have a way a verifying, since I have no Enterprise slack accounts. Maybe @focusaurus if you could take a look at
gh-slackand uh, see if you get yelled at by your IT team 😄I also tried with an Enterprise account. It kind of worked (i.e. I was able to login in slk, but I didn't see any message - though it's possible that I picked a workspace with no messages). Then, when I closed 'slk' it logged me out of Slack (all instances) and got an email (from Slack) "[Security notice] You've been signed out of Slack":
Hello,
We recently detected potentially suspicious activity associated with your Slack account. As a precaution, we’ve signed you out of the following Enterprise Grid organization:
User: XXXXX
Organization: YYYYYThe repo I linked works with enterprise slack but idk if maybe only for a subset of apis. Who knows how they’re detecting that stuff 🤷🏻
I'm on enterprise slack at work and following the regular token instructions got me booted out of all my login sessions, sent notices to my admins, etc. Presumably this is a security/compliance policy we have in place. Do you know if slk would need to be made available in the official slack app marketplace such that it could be potentially approved for use in a given enterprise workspace?
I can confirm I have the same issue,
slkgot stuck onConnecting, and I got booted out of the web sessions and received the same e-mail as quoted by @raff.- added a commit that references this issue
on May 20, 2026 So I took a look at things, and there is definitely some low-hanging fruit in terms of how the app is making calls to Slack. we weren't setting a
User-Agentand a bunch of other headers. #22 handles this now and works correctly. Could one of yall be brave enough to test-drive it and see if it fixes things for enterprise accounts?Just tried. It worked until I selected a channel, then it logged out all clients.
I am not sure if this was the same as before, since last time I tried our main company workspace, that didn't show any clients. Today I tried one of my team's workspaces.I have not been scolded by our IT department yet, so I am not sure if I am just get Slack's automated emails or if this is reported to our IT. I may let somebody else do the next test :)
- added a commit that references this issue
on May 20, 2026 Same as before. As soon as I select a channel, I get disconnected
29 remaining items
@raff — fantastic, thank you. That's the first Enterprise Grid org where slk is fully working, and your two logs are what got it there.
Your log also answered three open questions, so for the record:
users.conversationsis confirmed rejected (enterprise_is_restricted) — the fallback you exercised is now the permanent path on orgs like yours.- Most of your conversations are owned by the org itself, not a workspace: 218 of them carry the enterprise id (
E23RE8G4F) as their context team. Slack's edge cache accepts requests scoped that way but resolves none of them, so that part is still failing silently for you — harmless, just wasted requests and slower cache refresh. - The other 16 teams in your sidebar (1–42 conversations each) are ones your token can't read (
Unauthenticatedfrom the edge cache) — almost certainly Slack Connect / external teams. slk will stop asking about those once we know the right shape.
Two things follow from that, and you can help with the first:
- A 10-minute browser capture. The only way to see what the official client sends to the edge cache on a Grid org is to watch it. If you're up for it: open Slack in a browser on that org, open dev tools → Network → preserve log, then reload, click into a couple of channels, and save a HAR (right-click → "Save all as HAR with content"). Scrub anything sensitive (it contains your token) or just check it before sending — the only requests I care about are ones to
edgeapi.slack.com/cache/..., specifically what team id appears in the path and what theupdated_idspayloads look like. - No action needed: the next beta will stop spending those ~23 wasted requests per boot and batch the ~280 user-resolution calls you saw in the tally.
Thanks again — running an unreleased TUI against a production org and sending back logs twice is well beyond the call of duty.
Reacted by Peter LyonsGoing to officially close this one out as resolved. Thanks again raff!
Reacted by david ben-kalifa and Peter LyonsReacted by Chris M, david ben-kalifa and Peter Lyonswould be nice to more clearly state when you're letting AI respond directly.
- added a commit that references this issue
on Aug 23, 2026 - added 7 commits that reference this issue
on Sep 23, 2026
I'm on enterprise slack at work and following the regular token instructions got me booted out of all my login sessions, sent notices to my admins, etc. Presumably this is a security/compliance policy we have in place. Do you know if slk would need to be made available in the official slack app marketplace such that it could be potentially approved for use in a given enterprise workspace?