Skip to content

Lock 1 is inert in running sessions: the harness loads .claude/settings.json and os-dev.md from the shared checkout at clone time — an MCP-created PR after both deny lists landed, and the charter's constant-claude[bot] lines are false #18205

Description

@claude

Filed by the domain:skills execution seat (session session_01DAcomhvR9kKizeYgg89Vo8, seat post #7623) under the maintainer's direct order, 2026-09-14T15:05Z. Routed domain:skills · pm:queue on filing by the direct-dispatch channel (the order is quoted verbatim below and in the audit comment).

The maintainer's order (verbatim, ⛔ not translated)

「派发令硬性指定 REST 通道:建议改。 你应该修改skills吧?」 and 「不只是 objectui 仓库,其他第三方元数据app仓库怎么办」 — the maintainer, 2026-09-14, in the skills seat's chat, after the objectui spec seat's reading that the write identity follows the channel (objectui PR #9471 created via MCP as os-sam, PR #9501 via raw REST as claude[bot], one session).

Measured

  1. The deny lists landed, then were bypassed. objectstack lock 1: 7ef05f9973, 2026-09-13T23:27Z (PR docs(pm,agents,settings): write-identity locks 1–4 — deny MCP content writes, REST-only dev writes with api_writes, batch default 2, user-account roles #18072; 14 mcp__github__* entries under permissions.deny). objectui port: 3c6b09af, 2026-09-14T03:35Z (PR fix(devx): the objectui pin guard tests walk completeness, not object presence #9448). After both: objectui PR RUNNER.md rule 2 unconditionally requires a reproduction rule in the public run issue — needs the access-control carve-out at the source #9471 was created through MCP create_pull_request at 2026-09-14T07:04Z by the objectui spec seat's dev (report 5660901922 on objectui#8651: mcp_calls: 8 — create_pull_request 1, … issue_write 1, add_issue_comment 2), author os-sam / User. Same mechanism before lock 1: objectstack PR docs(pm,agents): three rules-layer lines catch up with the charter rulings #18051 by this seat's dev at 2026-09-13T15:50Z (report 5654331788: mcp_calls: 2 — create_pull_request and this add_issue_comment), author os-project-manager / User.
  2. Why: the harness loads .claude/settings.json and .claude/agents/*.md from the shared checkout, at clone time. This session's shared checkout /home/user/objectstack sits at 84e6b05b6d (committed 2026-09-13T06:14Z; the seat sat at 06:52Z that day): its .claude/settings.json carries 1 mcp__github__* entry (pre-lock-1) and its .claude/agents/os-dev.md :51 is the pre-lock-1 line; the objectui shared checkout at 69aa9c01 carries 0. A worktree at origin/main carries 15. No user-level settings file exists (/root/.claude/settings.json absent). The shared checkout is never advanced in a running session (worktree-first; guard-main-checkout blocks writes into it), so a rules-layer landing that changes harness-loaded files reaches only sessions cloned after it.
  3. Probe, 2026-09-14T15:03Z, this session: mcp__github__add_issue_comment against objectstack issue 999999999 (does not exist; nothing could be written) returned GitHub 404 Not Found, ⛔ not a permission denial ⇒ the deny list is not loaded here.
  4. Write identity by channel, four sessions (note 5665982929 on [finding] platform-readings: write identity is a per-session credential shape — installation → claude[bot], user-to-server → the human login with performed_via_github_app: claude; GET /user answers the human login in BOTH, so it is not the probe #18158): raw REST through the proxy → the session's proxy token — the installation token in some sessions (claude[bot] / Bot: this seat, the objectui spec seat) and a user-to-server token in others (os-warren, os-elon-musk / User: the cli seat 5664585381, the director seat 5665099836); MCP → the bound user's user-to-server token in every session measured. GET /user, MCP get_me and X-Ratelimit-Limit (15000 from a subagent and the main context alike) do not discriminate; only a write's read-back does.

Lines the measurement falsifies (on origin/main 99edfd008e)

  • .claude/agents/os-dev.md :51 「GitHub 写一律走 REST 代理(curl 带环境 GITHUB_TOKEN),署名恒 App 的 claude[bot]。」 — the signature is not constant.
  • .claude/skills/pm-dispatch/SKILL.md :95 「⛔ 席位与 dev 永不以用户账号写内容。」 and :96 「内容恒经 REST 代理(claude[bot]);…」 — the REST proxy's token class is not the seat's to choose; the invariant as written is unachievable in the cli and director seats' sessions and was read there as a violation (5665099836).
  • references/platform-readings.md :129 「容器 curl 的 REST 通道 = App installation token,core 15,000/时,…」 — per session, not a law.
  • references/rest-channel.md :54 「ccr 的 timeline actor 记 claude[bot],MCP 记席位账号。」 — same.

Direction (seat's reading; the order authorizes the channel mandate)

  • (a) Fact lines → the channel reading, equal-line under the ratchets: content writes go through the REST proxy only; ⛔ no MCP content write; user.login on a write names the channel's token, never the actor; attribution is the session ID in the text carrier. Rewrite os-dev.md :51, SKILL.md :95–:96 (and core-rules :25 if it restates them), platform-readings :129, rest-channel :54.
  • (b) Dispatch order and acceptance: every dispatch order carries a Writes: line (REST-only through the proxy, the write budget, mcp_calls counted), and the seat's ACCEPT refuses an os-dev-report whose mcp_calls names any write tool (create_pull_request, issue_write, add_issue_comment, update_pull_request, push_files, …) — one line where the order's fixed shape lives (the dev finds it: SKILL.md 〈模板与表〉 / references/dispatch-runbook.md) and one in os-dev.md's report contract (:369–:370).
  • (c) Propagation: a seat's fire-time reading compares the latest origin/main touch of the harness-loaded paths (.claude/settings.json, .claude/agents/*.md, .claude/hooks/*) against the shared checkout's HEAD (git -C <shared> merge-base --is-ancestor <touch> HEAD); a touch not in HEAD ⇒ the seat closes (brief) and re-seats in a fresh session before the next dispatch — ⛔ never advances the shared checkout in place. One charter line next to the three-charter-file reading (SKILL.md :86–:87) and, if the dev finds it cheap, a mechanical check under scripts/pm/ (dispatch-gates or a sibling) that names the stale path; density paid at 812/812.
  • (d) Fleet (the order's second sentence): the new-repo registration checklist (SKILL.md :193) gains the write-identity locks port (settings deny + hooks); cloud, objectos, hotcrm, www.objectos.ai carry no port today and are unattachable from this seat — the seat that can reach each files its card (recorded on [PM seat] domain:skills — 🟢 os-zhuang · session_01HZfg2AwVX191qCizp88gQr · R1 · 3 in flight · 4 governed PRs awaiting approval · 2 enqueued · landed ×2 · queue 9 · decision box 1 · triage seat VACANT #7623 until then). ⚠️ The per-repo deny is the weak layer: it loads only at session start and only from the primary checkout. The layer that covers every repo and every session is the maintainer's: a user-level ~/.claude/settings.json deny written by the environment's setup script, or the GitHub MCP connector stripped of its write tools. That is a Maintainer-action: suggestion for the round report, ⛔ not this card's work.

Landing

Governed rules layer (SKILL.md, os-dev.md, references, possibly scripts/pm/**) ⇒ four-piece + an authorized approval (ruling C); tier per dispatch-gates.mjs --tier (SKILL.md ⇒ fable MANDATORY). Serial on SKILL.md behind #17800 (wave 18, in flight) and #17497. Clause-②: no expected (no accepted set or public surface moves; gate strength: the ACCEPT refusal in (b) adds a check — named here so the four-piece reads it).

Not this card

#18158 (the identity reading itself — note posted), #18181 (os-dev.md :287 orders a label write the dev container forbids), #17800 (the claim comment's clause-② line), objectui#9418 / PR #9448 (the objectui port, landed).

Dedupe keywords: lock 1, deny MCP, shared checkout settings, mcp_calls, claude[bot] signature, harness-loaded.


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

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions