--- title: "Slack" description: "Start and follow Hoplite work from Slack, with optional channel-to-project routing." canonical_url: "https://hoplite.sh/docs/integrations/slack" markdown_url: "https://hoplite.sh/docs/integrations/slack.md" --- # Slack URL: /docs/integrations/slack LLM index: /llms.txt Description: Start and follow Hoplite work from Slack, with optional channel-to-project routing. Related: /docs/integrations, /docs/automations, /docs/threads # Slack Connect Slack to bring Hoplite into the channels where your team already works. ## Setup 1. **Install** — under **Settings → Integrations → Workspace**, connect your Slack workspace. This authorizes the Hoplite bot for every project in the Hoplite workspace and installs the scopes it needs to read channel lists and post messages. 2. **Optionally route a channel** — use the selected project's area of **Settings → Integrations** to choose a channel to route directly to a project. Channel selection is a picker over your actual Slack channels — no typing channel IDs by hand. ## How conversations route Hoplite routes each new Slack conversation in a fixed order: an exact channel route, the requester's personal default, the workspace default, and then Luna. Luna compares the request and its Slack context with every accessible project; a confident match starts the real user turn immediately and streams that run back into the Slack thread without a confirmation step. If none of those routes applies confidently, the requester opens a searchable Slack picker that can find every accessible project by project or repository name, including workspaces with more than Slack's 100-options-per-response limit. Each picker is bound to the Slack request that created it, so an older card or modal cannot accidentally start a newer pending request. README content, recent-thread evidence, and hidden Slack context remain available to the agent, but Hoplite does not copy that private routing evidence into the user-visible Slack response. Existing Slack conversations remain linked to the project that started them even if their channel route or saved defaults are later changed or disabled. When you ask Hoplite in Slack to start work in a project by name and several accessible projects share that name, it picks the one with the most threads unless you say which one you meant, and names the project it chose in its reply. ## Files and updates Files shared in the Slack conversation (images, videos, audio, and documents) are forwarded to the coding threads Hoplite starts or messages from it. Hoplite leaves them out only when they're clearly unrelated to that request. You can also ask the Slack assistant to send a file produced by a coding thread back into the conversation. It uploads the authorized thread attachment into Slack, rather than just sending a link. Older installations without `files:read` or `files:write` must be reconnected under **Settings → Integrations → Workspace** to receive or send files. Each time a coding thread started from the conversation stops, including after a PR autofix pass, Hoplite decides whether the Slack thread needs an update: relaying a question, reporting a failure, announcing a pull request, or saying it's ready to merge. Otherwise it stays quiet. Every open pull request the conversation hasn't seen yet is announced once with its link, and the link isn't posted a second time when the reply already contains it. The conversation's status card tracks the delegated thread from queued or running through its PR checks and final result. Its **Stop** action targets the run shown on the card. Hoplite edits the card as the state changes instead of posting a progress message for every transition; unsolicited notices in one Slack thread are limited to one per ten minutes. A Slack Connect requester is mentioned only when input is needed or a run fails. The assistant can inspect supported personal, project, integration, and workspace settings, subject to the requesting member's role and normal access permissions, but settings access from Slack and iMessage is read-only. Make changes in the Hoplite app. The assistant can't read back secret values or complete an MCP OAuth sign-in on your behalf. Workspace owners can edit the Slack agent's instructions under Slack settings; these instructions steer the assistant, not a coding thread's repository instructions. The assistant's own Slack conversation is free, with a daily limit per person and per workspace; the coding threads it starts are [billed normally](/docs/workspace/billing#whats-metered). ## Enable pull request autofix Ask Hoplite in Slack to enable autofix for a coding thread or a specific linked GitHub pull request, for example “Enable autofix for PR #123 in this thread.” Hoplite checks your thread and repository permissions, activates the CI and review fix loop, and confirms its state. This changes the selected PR, not workspace or project defaults, and does not enable auto-merge. Asking to monitor comments alone does not authorize automatic fixes. ## Slack Connect channels When both organizations in a shared Slack Connect channel have installed Hoplite, each organization's Hoplite answers only its own members. A mention goes to the Hoplite that was mentioned, and an unmentioned reply continues only a Hoplite that has already taken part in the thread. Messages from people outside your Slack workspace don't start a turn; they reach the agent with your next member's turn, marked as external, and the agent takes instructions only from the authenticated member. Someone who mentions another organization's Hoplite is told to use their own. ## Continuing in the web app When someone first continues a Slack-linked Hoplite [thread](/docs/threads) from the web app, Slack receives one handoff card with the generated thread title, project, effective model and effort, author, and an **Open in Hoplite** link. Later web messages stay in Hoplite without repeating that card, and the web prompt is never mirrored into Slack. By default the initial run's final answer also stays in Hoplite; an authorized workspace member can select **Continue in thread** on that active run to opt in to its answer. The opt-in is durable, so a result that finished before the click is replayed safely, while duplicate clicks do not duplicate the Slack answer. ## Make the app available to your workspace The Hoplite Slack app must have **unlisted distribution** enabled before it can be installed outside its Slack development workspace. In the Slack app dashboard, open **Manage Distribution**, complete the **Share Your App with Other Workspaces** checklist, then select **Activate Public Distribution**. Publishing in the Slack Marketplace is not required. The Slack app's **Options Load URL** must point to the same `/api/slack/webhook` endpoint as its Interactivity Request URL. Slack sends search queries from Hoplite's project picker to that URL; without it, the picker opens but returns no projects. If Slack shows `invalid_team_for_non_distributed_app`, the app has not yet been distributed (or distribution was disabled). An app owner must activate distribution, then start the connection again from Hoplite. If the channel picker comes up empty on an older installation, reinstall the Slack app from workspace integrations — channel listing requires scopes that early installs may not have granted. ## Slack automation triggers A Slack automation with **Anyone** as its sender filter accepts matching messages from people and other apps or bots, including bot messages without a user ID. **Authenticated Hoplite users** excludes bots and people who are not verified Hoplite workspace members. Hoplite ignores its own bot messages to prevent loops. This automation filter does not change who may instruct the interactive Slack assistant. ## Sitemap Sitemap discovery is not enabled for this deployment.