ChatGPT in Slack is a Python Bolt app that answers in threads, DMs and a Home tab

The file opens by telling you OpenAI now ships its own Slack app

The first thing in the README is a warning, not a feature list. The official Slack integration from OpenAI is available, with a marketplace link, and the text says you may want to try that first. That single line reframes everything that follows, and it is the honest reason to keep reading this repository only if you have a reason the marketplace app does not cover. Two practical notes come with it. There is a live demo, personally hosted by the author, and the guidance for corporate Slack workspaces is to deploy on your own infrastructure rather than route company conversation through someone else's demo. For anyone evaluating the hosted alternative, there is also a sibling repository for Slack's next generation platform, written against api.slack.com/future rather than classic Slack apps. In other words the choice is three-way: use OpenAI's own app, run this one yourself, or look at the Deno-based version if your workspace is on the newer platform.

Three interfaces, and only the channel thread needs a mention

The bot exposes three surfaces, and the split is by audience rather than by feature. Channel threads are the right choice when you want other people in the workspace to see the conversation: you mention the bot in a thread's first message and then talk to it normally for the rest of that thread without mentioning it again. A direct message is the private option, where no mention is needed at all. The Home tab is the third surface and is where the app configuration lives, including the OpenAI API key and model settings, alongside a quick proofreader, a free prompt sender dialog for firing off a question from a phone, and a from-scratch modal for anything else. Image generation is available there too by describing a picture for DALL-E 3. Thread memory is the other behaviour worth knowing: within one thread the bot remembers what was already said, so the workflow described is to ask loosely for a business email, read the draft, then adjust the details rather than trying to phrase the first request perfectly.

manifest-dev.yml creates the app, and the token scopes are the fiddly part

Running it locally is four steps: create a new Slack app using `manifest-dev.yml`, install that app into your workspace, fetch an OpenAI API key from platform.openai.com, then start the app. There is a second manifest, `manifest-prod.yml`, for the deployed version, and a `serverless.yml` at the root for a serverless packaging path, with `main.py` and `main_prod.py` as the two entry points. The environment variables are where newcomers lose time, and the reasons are spelled out in comments:

# Create an app-level token with connections:write scope
export SLACK_APP_TOKEN=xapp-1-...
# Install the app into your workspace to grab this token
export SLACK_BOT_TOKEN=xoxb-...
# Visit https://platform.openai.com/account/api-keys for this token
export OPENAI_API_KEY=sk-...

The app level token needs the `connections:write` scope, and the ordering matters because you can only read the bot token after the app is installed into the workspace.

The default model is gpt-5.6-luna and three optional vars tune the call

Three more variables are optional and each changes one thing about the OpenAI call:

# Optional: Choose a supported model (default: gpt-5.6-luna)
export OPENAI_MODEL=gpt-5.6-luna
# Optional: Model temperature between 0 and 2 when supported (default: 1.0)
export OPENAI_TEMPERATURE=1
# Optional: You can adjust the timeout seconds for OpenAI calls (default: 30)
export OPENAI_TIMEOUT_SECONDS=60

The comments are honest about limits: temperature only applies when the model supports it, and the timeout default is 30 seconds, raised to 60 in the example. Note that the environment file only carries the three credentials, so anything you tune goes into your shell or your own deployment configuration. If you would rather not export variables during development, the supported alternative is to copy the example file and fill it in:

cp .env.example .env

with `OPENAI_API_KEY`, `SLACK_BOT_TOKEN` and `SLACK_APP_TOKEN` as the three keys, loaded through python-dotenv, which is in the dependency file.

Socket Mode is why no public URL is required

The deployment advice is to fork and run it on infrastructure you manage, and the container image is at the repository root. What makes that practical is the transport: the app opens a WebSocket connection to Slack using Socket Mode, so there is no inbound public URL to expose and no tunnel to maintain. The Dockerfile is a two stage build on `python:3.11.15-slim-bookworm`, with a builder that installs `requirements.txt` and an app stage that copies only `*.py` and `app/*.py` plus the installed `bin` and `lib` trees from the builder, then runs `python main.py` as its entry point. The comment block at the end of the file gives the matching `docker build` and `docker run` lines, and both Slack tokens and the OpenAI key are passed as `-e` flags at run time rather than baked into the image. If you deploy this anywhere shared, that is the shape to copy: build once, inject secrets per environment.

tiktoken carries two ranges and urllib3 is held below 2

The dependency file is short and the pins have stories attached. `slack-bolt` is held at 1.x, `slack-sdk` at 3.x and `openai` at 1.x, each with an upper bound below the next major. `tiktoken` appears twice with environment markers, one range for Python below 3.14 and a newer range for 3.14 and above, with a comment explaining that the existing pre-3.14 range is kept while 3.14 installs are allowed. `urllib3` is capped below 2, and the comment above it links a specific issue rather than leaving the constraint unexplained. `pillow` is needed for the image handling, `requests` and `python-dotenv` for HTTP and file based configuration. The linting story matches the pinning attitude: the repository ships a `.flake8` config and a `validate.sh`, and the contribution notes say to run it before committing because it runs black as formatter plus flake8 and pytype as static analysers.

validate.sh, unit tests around app/markdown.py, and a description that says Swift

The contribution guidance is specific rather than ceremonial. Breaking behaviour changes are to be avoided, and if one is unavoidable for a critical reason such as security, the instruction is to open a GitHub issue and discuss before altering anything. Tests are requested with a pointed example: internal utility modules such as `app/markdown.py`, and any code that does not call a web API, are easy to cover and should be. There is an `AGENTS.md` at the root and a `tests/` directory. One entry in the repository metadata is wrong in a way worth knowing about, since the project description says it is a Swift demonstration while the primary language is recorded as Python and the codebase is Python, using Slack Bolt and `main.py`. Version history is thin as well: no GitHub releases, not archived, last push to main on 2026-08-30. For a fork that supports other providers, the pointer is to `iwamot/collmbo`, which adds LiteLLM so the OpenAI call can be swapped for other vendors. The MIT licence applies, and the repository also carries a `LICENSE` file rather than relying on the badge alone.

Editorial conclusion

Treat this repository as a reference implementation rather than a product to depend on. It earns its place as a compact, readable example of a Slack Bolt app with Socket Mode deployment, three conversation surfaces and OpenAI API calls, and the author is candid that the official OpenAI Slack app now exists and that corporate workspaces should self-host rather than use the public demo. Skip it if you just want ChatGPT in Slack, because you would be reimplementing a marketplace app with three API keys to manage. Before you fork it, read the two token variables carefully since the app level token needs the connections:write scope and is only visible after installation, note that the repository description says Swift while the code is Python, and check that your runtime can satisfy the dependency ranges, which hold urllib3 below 2 and give tiktoken two different versions depending on whether you are on Python 3.14 or older.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. seratch/ChatGPT-in-Slack on GitHub