[BUG] Cowork Intercom connector — update_article fails with permission error after working earlier in session

Resolved 💬 4 comments Opened May 5, 2026 by kris-seavey Closed May 9, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

What to include in the report:

"Cowork mode, Intercom connector"
The error message: "This connector requires additional permissions. The user needs to reconnect it with the appropriate access."
"update_article calls fail with this error; get_article works (reads OK, writes blocked)"
"Worked fine for ~14 successful pushes on 2026-05-05, then broke mid-session"
"Reconnected the connector multiple times, also fully removed and re-added — error persists"
"Verified the underlying Intercom internal app has Read+Write scopes for articles"
(Optional) Connector ID: 19bd23b5-7ad8-45d2-9024-e6bfc4762da0

What Should Happen?

The updated article should be posted to intercom successfully, just like the 14 that were done prior. But now its not allowing it at all, and claude is saying its on cowork side

Error Messages/Logs

Steps to Reproduce

Title: [BUG] Cowork Intercom connector — update_article fails with permission error mid-session despite working initially
Environment

Cowork mode (research preview), macOS
Intercom MCP connector (connector id: 19bd23b5-7ad8-45d2-9024-e6bfc4762da0)
Underlying Intercom internal app has Read+Write scopes enabled for articles (verified in Intercom Developer Hub)
Date observed: 2026-05-05, ~7-8 PM ET

Summary
The Intercom connector starts a session with full read/write access — update_article, get_article, list_articles, search_articles all work. After several successful update_article calls, write operations begin failing with a permission error while reads continue to succeed. Reconnecting the connector — including a full remove-and-re-add — does not restore write access.
Steps to reproduce

Connect the Intercom MCP connector in Cowork using an Intercom internal app that has Read+Write articles scope.
In a single Cowork session, perform a series of update_article calls (in my case, I performed 14 sequential pushes successfully across roughly 1.5–2 hours, each updating the body and/or title/description of a different article).
Continue using the connector — eventually update_article starts returning the error below. In my case it broke on the 15th attempt; not sure if it's count-based, time-based, or token-refresh-related.
Continue calling get_article — these still succeed normally.

Expected behavior
update_article continues to work for the duration of the session, given that:

The underlying Intercom internal app has the correct scopes
Reads (which use the same connector and the same auth) continue to succeed

Actual behavior
update_article returns:
This connector requires additional permissions. The user needs to reconnect it with the appropriate access.
get_article, list_articles, search_articles all continue to work without issue.
Troubleshooting attempted (none restored write access)

Reconnected the Intercom connector via Cowork settings (×2)
Fully removed the Intercom connector and re-added it from scratch
Confirmed the Intercom internal app's permissions in Intercom Developer Hub — Read+Write articles are both enabled (screenshot available on request)
Verified the access token on the Intercom side hasn't been revoked
Closed and reopened the Claude desktop app between attempts

Hypothesis
Reads and writes appear to use different scope grants in the Cowork-side OAuth state. When reconnecting via Cowork's UI, the OAuth flow may be re-establishing the read scope but not re-requesting the write scope. The error message implies a scope mismatch at the connector layer rather than the underlying Intercom app.
Impact
Mid-workflow blocker. I was performing a structured rewrite of ~440 published help-center articles and had 14 done before this hit — the remaining articles can't be pushed live until this is resolved (local rewrites still queue up, but no way to publish without write access).
Files / artifacts

Local rewrite ready to push at the time of failure: article id 14188046 (Enhanced Integration). Available if you'd like the body HTML for a repro test.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.121

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗