seratch/ChatGPT-in-Slack: a Slack bot for ChatGPT, installed from a manifest

What ChatGPT-in-Slack is for, and who it is actually for

The project is a Slack app that lets people in a workspace talk to ChatGPT without leaving Slack. The README frames the benefit around planning and writing: you ask in a channel thread, a DM, or a modal on the Home tab, and the bot answers. Because the conversation lives in a Slack thread, other people in the channel can read it and add to it, which is the one thing a browser tab full of ChatGPT conversations does not give you.

The intended audience is not end users who want a hosted bot. It is people who can run a Python process or a container and who are willing to create their own Slack app and supply their own OpenAI key. The README says as much: for corporate Slack workspaces it advises deploying the app on your own infrastructure using the guidelines in the repository. There is a live demo hosted personally by the maintainer, but the README is explicit that this is a personal host, not a service.

The first line of the README is a warning pointing at OpenAI's official Slack integration, and it says you may want to try that first. That is unusual honesty in a project README, and it should shape how you read the rest of the page. This repository is a working demonstration of the Slack and OpenAI APIs wired together, not a product with a support commitment.

How the bot keeps context inside a Slack thread

The mechanism the README describes is conversation memory scoped to a thread. While you are communicating in the same thread, the bot remembers what you have already said. That means the app is not stateless per message: it has to hold or reconstruct the earlier turns of the thread and resend them with each new prompt, which is why the OpenAI call takes a timeout setting and why token counting matters enough for tiktoken to be a dependency.

There are three interfaces, and the README ranks them by visibility. Channel threads are the recommended option when you want to share a conversation with others in the workspace. A 1:1 DM is the private option, and no mention of the bot is needed there. The Home tab offers a quick proofreader and a free prompt sender, plus an OpenAI API key and model configuration panel, which the README notes is convenient from a mobile device.

Two optional behaviours change what leaves your workspace. With TRANSLATE_MARKDOWN set to true, the app translates between OpenAI markdown and Slack mrkdwn format, which is off by default. With REDACTION_ENABLED set to true, the app performs some basic redaction on prompts sent to OpenAI, also off by default. Both defaults mean the raw prompt goes out as typed unless you intervene. The README does not describe what the redaction rules actually match, so treat that flag as a boundary you have to inspect in the code before you rely on it.

Installing ChatGPT in Slack from the manifest and running it locally

The repository ships two Slack app manifests, manifest-dev.yml and manifest-prod.yml, and the local instructions start by creating a new Slack app from the dev manifest. You then install that app into your workspace to obtain a bot token, and create an app-level token with the connections:write scope. The OpenAI key comes from the platform's API keys page.

The tokens are read from the environment. The README exports them directly; the repository also ships .env.example for loading them from a file.

cp .env.example .env

The example file contains three keys, and you replace the placeholder values with your own.

OPENAI_API_KEY=sk-...
SLACK_BOT_TOKEN=xoxb-...
SLACK_APP_TOKEN=xapp-1-...

The remaining settings are optional and have defaults. OPENAI_MODEL selects the model, OPENAI_TEMPERATURE takes a value between 0 and 2 where the model supports it, and OPENAI_TIMEOUT_SECONDS controls how long the app waits on OpenAI, defaulting to 30. OPENAI_SYSTEM_TEXT lets you prime the bot with instructions, and USE_SLACK_LANGUAGE, on by default, translates prompts into the user's preferred language.

export OPENAI_SYSTEM_TEXT="You proofread text. When you receive a message, you will check
for mistakes and make suggestion to improve the language of the given text"

With the environment set, the run sequence is a virtual environment, a requirements install, and the entry point.

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python main.py

The repository also includes a Dockerfile. It builds from python:3.11.15-slim-bookworm in two stages and sets the entry point to python main.py, so you can build an image and run it with the three token variables passed through. The Dockerfile's comments give the build and run commands. The README does not document a health check endpoint or a readiness probe, so if you put this behind a load balancer you are on your own for liveness.

Azure OpenAI, model pinning and the configuration trap

The app supports Azure OpenAI through three environment variables: OPENAI_API_TYPE set to azure, OPENAI_API_BASE pointing at your resource, and OPENAI_DEPLOYMENT_ID naming your deployment. The README notes that v1 of the Azure API does not use dated API versions, so any existing OPENAI_API_VERSION setting should be removed.

The awkward part is documented in a comment: the app uses one Azure deployment for both chat and translation. If you are upgrading from an older model, you have to replace that deployment and align both OPENAI_MODEL and any model selections saved in the workspace with the new name. Legacy or mismatched deployments are described as incompatible with the new request parameters. In practice that means a model change is not a single environment variable edit; it is a coordinated change across the Azure deployment, the process environment, and per-workspace state that users set through the Home tab. If you run more than one Slack workspace against one deployment, plan the cutover.

The same class of problem applies outside Azure. The default model named in the README is a specific identifier, and nothing in the repository validates it against your account before the first request. A wrong model name surfaces as an API error at the first prompt, not at startup. Setting OPENAI_MODEL explicitly and testing one prompt before telling users the bot exists is the cheap way to find that out.

Where this app is the wrong choice

The README's own warning is the strongest limitation: OpenAI ships an official Slack integration, and the project tells you to try it first. If your requirement is simply that ChatGPT appears in Slack, the official integration removes the deployment, the token management and the model configuration from your plate entirely.

The second limitation is that this is a demonstration. There are no releases in the repository, so there is no version to pin, no changelog to read, and no upgrade path other than tracking commits on the main branch. The README documents no rollback procedure and no migration notes beyond the Azure model comment. If your organisation needs a vendor to point at when something breaks, this is the wrong shape of dependency.

Third, the privacy defaults are permissive. Redaction and image file sharing are both off by default, and the README does not describe the redaction rules. In a workspace where people will paste customer text into a thread, the bot will send that text to OpenAI unchanged unless you turn redaction on and verify what it does. That is a policy decision the app leaves to you.

Finally, the timeout default is 30 seconds with a note that you can raise it. Long prompts and slow model responses will hit that ceiling, and the README does not describe what the user sees when the call times out.

The alternative in the same repository: chatgpt-on-deno

The README points to a sibling project, seratch/chatgpt-on-deno, for people who want a sample app running on Slack's next-generation hosted platform. The difference is architectural rather than cosmetic. This repository runs a long-lived Python process that holds a WebSocket connection to Slack, which is why it needs an app-level token with connections:write and why it can be run with python main.py or as a container. The Deno sample targets a hosted platform model, where Slack runs the app rather than you running a process that connects out.

That distinction drives the operational cost. A socket-mode process has to stay up, be restarted when it dies, and be reachable to Slack for the duration of the connection. A hosted-platform app moves that concern to the platform. If your team has no appetite for running a container, the Deno sample is the more natural starting point, and the README says so directly.

There is also the plain alternative of not building anything: the official OpenAI Slack integration. Between the three options, this repository sits in the middle. It gives you more control than the official integration and less operational burden than writing your own Slack and OpenAI glue, at the cost of owning the deployment.

Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-08-30. There are no releases, so there is no tag to upgrade between and no published compatibility matrix. Upgrading means pulling the latest main and reconciling your environment with whatever the code now expects, which is exactly the situation the Azure model comment describes.

The dependency ranges in requirements.txt are pinned with upper bounds: slack-bolt below 2, slack-sdk below 4, openai below 2, pillow below 12, requests below 3, python-dotenv below 2. tiktoken is split by Python version, with a range for interpreters below 3.14 and a separate range at or above it. urllib3 is held below 2 with a comment linking to an unrelated project's issue, which suggests a transitive dependency constraint rather than a direct need. Those bounds limit how far a fresh pip install can drift, but they also mean you will eventually hit a ceiling that requires editing the file.

The Dockerfile pins the interpreter to python:3.11.15-slim-bookworm in both stages, so the container path is insulated from Python version drift until you choose to move it. The licence is MIT. In practical terms that permits commercial use and modification provided the copyright notice and permission notice are retained, but the repository is a demonstration and the licence says nothing about the OpenAI or Slack terms you accept separately by using their APIs. That is a question for your own counsel, not for this README.

Editorial conclusion

Adopt it if you want ChatGPT inside your own Slack workspace with your own credentials, your own model settings and a deployment you control, and if you are comfortable running a Python process or a container. Skip it if you just want ChatGPT in Slack and nothing else: the README's first line directs you to OpenAI's official Slack integration, and this project is a demonstration rather than a product. Before deploying, verify three things: that the model name you set in OPENAI_MODEL is one your OpenAI account can actually call, that your Slack app's token scopes match what the manifest creates, and that your OpenAI key is stored somewhere other than a shell history. The repository has no releases, so pinning a tag is not an option; pin a commit instead.

Frequently asked questions

Official sources

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