Prevent passive Slack thread participants from receiving plugin OAuth prompts

未关闭
  • 哪里不对？
#1,377 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
typescript
领域
authentication, backend-api-design

调研方向

从 SlackTurnRuntime.handleSubscribedMessage 开始，追踪 conversation-store actor 的来源如何传递到 MCP 身份验证，并比较活跃和空闲的已订阅会话。使用复现用例和验收用例，为跨 actor 的被动回复、显式提及和 OAuth 传递增加覆盖；完成的标准是保留上下文而不改变权限，并且不向任何无关参与者发送 prompt。

由索引模型根据 Issue 内容生成。

描述

Problem

Junior treats the author of every subscribed Slack reply as the actor for a new turn, even when that person only joined an existing thread to provide context.

This produces a bad OAuth flow in shared threads:

  1. Alice asks Junior to debug an engineering problem.
  2. Junior begins an investigation that uses an authenticated MCP plugin such as PlanetScale.
  3. Bob replies without mentioning Junior and adds support context, an identifier, or a correction.
  4. The subscribed-reply router decides Bob's message continues Junior's work.
  5. Junior starts the turn with Bob as the actor.
  6. When PlanetScale requires authentication, Junior sends Bob an OAuth link.

Bob never requested PlanetScale access, may not have a PlanetScale account, and did not take ownership of the investigation. The original task also stalls waiting for an authorization Bob cannot complete.

Current behavior

SlackTurnRuntime.handleSubscribedMessage assigns the latest message author as the turn actor:

const actorId = isResourceEventNotification
  ? undefined
  : message.author.userId;

MCP authentication then creates and delivers the authorization request for that actor:

userId: input.actorId

The conversation store already preserves the original conversation actor when another Slack user participates, but the subscribed-turn runtime does not use that distinction.

Plugin manifests also have no audience or eligibility configuration. Every actor can reach every plugin's OAuth flow if the model selects its tools.

Expected behavior

Posting a passive reply in a subscribed thread must not implicitly make someone the task authority or credential principal.

  • A cross-actor reply without an explicit Junior mention may contribute context to the existing task.
  • It must not trigger an OAuth link for its author.
  • It must not authorize new work or broaden the original task.
  • Junior may continue using the task owner's authority only within the work that owner already requested.
  • If attribution is ambiguous, Junior should wait for the task owner instead of asking the incidental participant to authenticate.
  • An explicit mention from another actor may start a separate turn under that actor's credentials.
  • Junior must never reuse the task owner's credentials for a new request from another participant.

Reproduction

  1. Alice mentions Junior in a Slack thread and requests an investigation that requires an MCP plugin.
  2. Alice has authorized the plugin.
  3. Allow the initial turn to complete or pause.
  4. Bob replies in the same thread without mentioning Junior.
  5. Make Bob's reply a natural continuation, such as supplying the requested record ID.
  6. Observe Junior send Bob the plugin OAuth link.

Acceptance

  • Passive cross-actor subscribed replies never send their author an OAuth link.
  • The message remains available as attributed conversation context.
  • Existing task authority and credential ownership do not silently change.
  • Explicit cross-actor mentions remain separate actor-owned turns.
  • Tests cover both active and idle subscribed conversations.

Related

  • #773 tracks actor and instruction provenance across multi-actor runs.
  • #956 tracks cross-actor mentions arriving during an active run.
  • This issue covers the remaining subscribed-thread case where an incidental participant becomes the actor for a later turn and receives an unintended OAuth prompt.
主要语言
TypeScript
星标
397
派生
43
平均合并
7 小时 55 分钟
30 天内合并 PR
661

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

getsentry/junior 的其他 Issue

查看 getsentry/junior 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。