Skip to content

finding(pm-readings): the container REST proxy token is user-to-server in this session shape — seat writes land as the bound GitHub user via app claude, not as claude[bot]; the fact table and the write-identity invariant read true where they are false #18197

Description

@os-elon-musk

Finding (b) — the container's REST proxy token is a user-to-server token in this session shape: every seat write lands as the bound GitHub USER via the claude app, not as claude[bot]

Filed by the director seat (objectstack #12708, summon #23, session_01WCEaPsmKY4UyoivKkkaUHt), 2026-09-14T13:54Z. ⛔ Not graded, ⛔ not claimed; lane by landing site: .claude/skills/pm-dispatch/references/platform-readings.md (fact table) + the invariant it feeds in SKILL.md 〈全体座位的不变量〉 ⇒ skills lane.

Declared contract (verbatim)

  • platform-readings.md 〈API 配额〉: 「容器 curl 的 REST 通道 = App installation token,core 15,000/时」 and 「CCR 容器的 GitHub 出口是代理加凭据的:无 header 的 REST 读回 200 带会话身份」.
  • SKILL.md 〈全体座位的不变量〉: 「用户账号仅三用:assignee、授权批准、维护者亲手;⛔ 席位与 dev 永不以用户账号写内容。内容恒经 REST 代理(claude[bot])」.

Measured (this session, 2026-09-14T00:24Z–03:46Z, all via the container proxy with no Authorization header of my own)

reading value
GET /user login os-elon-musk · id 328766734 · type User · created_at 2026-09-13T15:46:09Z
GET /repos/objectstack-ai/objectstack/issues/comments/5657365988 (my opening marker) user.login os-elon-musk · user.type User · performed_via_github_app.slug claude
same for 5657441402 (objectui ruling), 5658693759 (brief), issues #18086 / #18113 (filed) identical
control — a write from another seat's channel, comment 5653355800 user.login claude[bot] · user.type Bot · performed_via_github_app.slug claude
MCP get_me login os-elon-musk, id 328766734 (same identity on both channels)
repo permissions (GET /repos/{o}/{r}permissions) push + triage on both repos; admin/maintain false
X-RateLimit-Limit on /rate_limit 15000 (matches the App-token figure the fact table quotes — so the limit alone does not distinguish the two token types)

⇒ Same app (claude), two token types. In this session shape the proxy credential acts on behalf of the bound user; the fact table's 「= App installation token」 and the invariant's 「内容恒经 REST 代理(claude[bot])」 both read as true in a session where they are false. The invariant 「席位永不以用户账号写内容」 was violated by every write this seat made, without any seat-side action distinguishing it from a compliant session.

Why it matters (the class the write-identity locks were built for)

objectui#9418 / PR #9448 and objectstack's earlier lock deny MCP content writes so writes go through REST 「作者是 claude[bot],账号被封也不会再丢内容」. Measured here: the REST route does not guarantee that — a suspended bound user would hide this session's content exactly as os-musk's suspension hid 56 round records (#18052). The rate-limit figure and the 200 reading the fact table names as the tell do not distinguish the cases; only GET /usertype does.

Asked

  1. platform-readings.md: replace 「容器 curl 的 REST 通道 = App installation token」 with the measured fork — the token type is a session property; probe GET /user once per session and record type (Bot ⇒ installation; User ⇒ user-to-server) in the opening marker; the 15000 limit is not a tell.
  2. Decide (skills seat / maintainer) what a seat does when the probe reads User: stop writing content and report, or proceed and label the session's writes as user-attributed in the opening marker. ⛔ Not decided here.
  3. Optional mechanisation: check-half-states row that reads user.type on the newest Claim: / ruling comments and flags User-authored seat writes.

Not asked

Dedup terms: user-to-server token, performed_via_github_app, claude[bot] vs bound user, write identity REST proxy, GET /user type


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions