Sume team chat says View only: 403 Missing capability

Members are read-only in a Sume team workspace. The composer is disabled and write routes answer 403 Missing capability thread.run or thread.write.

5 min readSume
All posts

If a teammate in your Sume workspace sees a disabled composer reading "View only - Creators and Admins can message and run this chat", or a request fails with 403 Missing capability: thread.run, their role is Member. Members can open and watch every team thread but cannot write or run. Ask an Admin to change the role to Creator.

What the message means

Team threads are shared with every workspace member for reading. Writing and running are separate capabilities, thread.write and thread.run, and both belong to Admin and Creator only. The web client turns the exact messages Missing capability: thread.run and Missing capability: thread.write into the friendly View-only copy instead of a raw error.

The same rule covers sending, queueing a follow-up, forking, resubmitting a turn, and Stop on a running job. Cancel is a run action, so a Member cannot stop a job either.

What a Member can still do

  • Open any non-archived thread in the workspace and read the transcript.
  • Watch a live job: job GET and the progress stream are read operations, so the Working band and streaming tokens show for anyone who can open the thread.
  • Read the shared Product, Action, Skill and Asset libraries.
  • Archive a thread they own themselves. Archiving someone else's thread is Admin-only.

Why the rule changed

The project history in the team docs is a useful warning: all members could write at first, then Member was made read-only, then that was reversed, and the 2026-09-03 decision restored read-only for Members and extended it to running actions. If an old screenshot or a colleague says every member can chat, the current code is the authority.

The fix and the check

Role changes are an Admin task (members.manage). After the change, the Member needs to reload so the capability role is read again. Do not work around it by sharing one login: spend is attributed to the member who acts, and the team wallet is billed, so a shared login blurs both the ledger and the author shown on each turn.

If you are building a client on the web routes, treat a 403 with that message as a permissions state to display, not as a transient error to retry.

Authorship in a shared thread

Each user turn records the member who sent it, separate from the thread owner, so the transcript can show who asked what. Follow-ups queued while a turn is live show the enqueuer's avatar and name on one shared Queued card, and they drain one at a time: each waits until the previous job is terminal. Cost goes to the member who acts and bills the workspace wallet. For a Member who wants something run, the practical path is to ask a Creator in the thread's comments, which are human-only side notes that never enter the model prompt.

A final edge: removing a teammate, as opposed to changing a role, is also an Admin action under members.manage. Removed members lose workspace access, though the team docs list one known gap: API keys a removed member already minted stay warm until key revocation lands, so an Admin should revoke those keys by hand.

Related posts

More in Agents

All Agents posts

Written by Sume