Boot-time identity collision check — Desktop-session extension (ORA-2026-0032)

Observation

On 2026-04-20, two Claude Code Desktop sessions running concurrently on the same MacBook-Air (chadbarlow@MacBook-Air) independently adopted the identical fleet seat ID CLAUDE-DESKTOP-MacBook-Air-ORA-01. Neither session detected the other at boot, and both signed downstream artifacts under the same identity. Session 1 (Claude Code Desktop window titled "Financial Pipeline") produced four architecture documents in /Users/chadbarlow/Desktop/fleet/. Session 2 (window titled "Communications Pipeline (ora 01)") produced an unpack document in the iCloud-synced ~/Library/Mobile Documents/com~apple~CloudDocs/camberzero_sync_assets/ora/ directory. Both sets of artifacts carry the same author signature.

The ORA-2026-04-16 boot-time identity negotiation doctrine exists specifically to prevent this: it instructs every new session to resolve PLATFORM and INSTANCE by querying fleet-active-queue + worktree mtime before adopting a seat name. In this case, the doctrine's detection surfaces were blind to both sessions because neither session's work pattern touched them. Neither session posted to FLEET_FEED.md before starting doc-production work, so fleet-active-queue (which reduces over the feed) had no record of the seat claim. Neither session was using a git worktree (Desktop app doc-production, not code work), so the find ~/gh/-worktrees/-<LANE>-<NN>-* -mmin -60 check returned nothing. And the Claude Code Desktop harness itself provides no cross-session introspection — two Desktop app windows on the same machine cannot see each other's identity claims through any native mechanism.

This is structurally distinct from ORA-2026-0064's session-cron queue collision (single session, two cron prompts coalesce in one message queue) and from ORA-2026-0014's identity parity gap (boot-surface drift across machines). Here, two independent sessions on the same machine both passed the existing boot-time check honestly and both landed on the same answer, because the check's evidence surfaces don't cover the doc-production work pattern.

Evidence

1. Session 1 artifact: /Users/chadbarlow/Desktop/fleet/ARCHITECTURE_LLM_AT_JOINTS.md — produced 2026-04-20 by Claude Code Desktop window "Financial Pipeline", signed CLAUDE-DESKTOP-MacBook-Air-ORA-01. Three additional arch docs in the same directory carry the same signature from the same session.

2. Session 2 artifact: /Users/chadbarlow/Library/Mobile Documents/com~apple~CloudDocs/camberzero_sync_assets/ora/unpack_desktop_ora01_financial_pipeline_20260420.md — produced 2026-04-20 by Claude Code Desktop window "Communications Pipeline (ora 01)", also signed CLAUDE-DESKTOP-MacBook-Air-ORA-01.

3. Identical author signature across both sets: Both sessions adopted the string CLAUDE-DESKTOP-MacBook-Air-ORA-01 as their fleet seat ID. There is no existing provenance marker in either artifact set that distinguishes which physical session produced which file.

4. Detection-surface miss: fleet-active-queue run during the collision window showed zero claims under CLAUDE-DESKTOP-MacBook-Air-ORA-01 because neither session had posted an actionable to FLEET_FEED.md. find ~/gh/-worktrees/-ORA-01-* -mmin -60 returned empty because neither session was touching a worktree. Both sessions passed the boot-time identity check as currently specified — and both got the wrong answer.

Implications

• Provenance corruption: downstream citations referencing "work done by CLAUDE-DESKTOP-MacBook-Air-ORA-01 on 2026-04-20" are ambiguous by construction. Any future audit, ORA entry, or ad-fontes verification that traces authorship back to this seat on this date will hit two disjoint artifact sets without a deterministic way to separate them.

• Parallel-work double-spend risk: if two sessions believe they are the sole occupant of a seat, they may independently claim the same ticket, file duplicate follow-ons, or redundantly consume the same feed entry. The 2026-04-20 case was adjacent collaboration (two different doc streams), but the same collision under actionable-work conditions would burn fleet cycles on duplicated effort.

• Doctrine-compliance ≠ correctness: both sessions followed the ORA-2026-04-16 boot-time identity protocol faithfully. The doctrine is under-specified for the doc-production work pattern. Seats can be rigorously compliant and still collide, which is a class of failure the doctrine does not yet acknowledge.

• iCloud-synced assets are a blind spot: ~/Library/Mobile Documents/com~apple~CloudDocs/camberzero_sync_assets/ is a shared-surface write target for Desktop sessions but is not part of any current boot-time check. Sessions writing there are effectively invisible to the rest of the fleet until they post to a feed.

• Desktop harness opacity compounds it: because Desktop sessions cannot be claude --resumed and cannot introspect each other, Chad is the only observer who can disambiguate them — and the disambiguation surface (window titles) is not machine-readable from inside the session.

Recommended mitigation

Extend the ORA-2026-04-16 boot-time identity check with a third evidence surface: a scan of recently-written shared-surface artifacts for author-signature hits on the proposed seat ID within the last 24 hours. Every Desktop Claude Code session runs this 2-line bash preamble before announcing its seat:

# Boot-time identity collision check — Desktop-session extension (ORA-2026-0032)
PROPOSED_SEAT="CLAUDE-DESKTOP-MacBook-Air-ORA-01"  # initial candidate from PLATFORM+LANE resolution
SINCE_HOURS=24
FEED_HITS=$(grep -l "author: ${PROPOSED_SEAT}\|OWNER: ${PROPOSED_SEAT}\|${PROPOSED_SEAT}" \
  /Users/chadbarlow/Desktop/FLEET_FEED.md 2>/dev/null | wc -l)
ICLOUD_HITS=$(find "/Users/chadbarlow/Library/Mobile Documents/com~apple~CloudDocs/camberzero_sync_assets" \
  -type f -mtime -1 -exec grep -l "${PROPOSED_SEAT}" {} \; 2>/dev/null | wc -l)
DESKTOP_HITS=$(find "/Users/chadbarlow/Desktop/fleet" -type f -mtime -1 \
  -exec grep -l "${PROPOSED_SEAT}" {} \; 2>/dev/null | wc -l)
TOTAL_HITS=$((FEED_HITS + ICLOUD_HITS + DESKTOP_HITS))
if [ "$TOTAL_HITS" -gt 0 ]; then
  # Bump NN, re-probe, announce collision-avoidance in opening feed post
  # e.g. CLAUDE-DESKTOP-MacBook-Air-ORA-01 -> -ORA-02
  echo "COLLISION: ${PROPOSED_SEAT} has ${TOTAL_HITS} recent artifact hits; bumping NN"
fi

Pseudocode semantics: (1) the check fires at boot, after the existing PLATFORM+INSTANCE resolution produces a candidate seat ID; (2) it scans three evidence surfaces (FLEET_FEED.md, iCloud camberzero_sync_assets, local Desktop fleet surface) for recent signature hits; (3) if any hits are found within the lookback window, the session auto-bumps NN and re-probes until the candidate is clean; (4) the session's opening feed post must announce the collision-avoidance (e.g. "Bumped from ORA-01 to ORA-02 at boot — prior-24h artifact hits on ORA-01"). This closes the gap for doc-production work patterns that don't touch feeds or worktrees. A secondary fix — a harness-level claude --list-sessions primitive — would solve it more cleanly but is upstream of this observation's scope.

Related doctrines / failures

• ORA-2026-04-16 boot-time identity negotiation — the doctrine this observation extends. Current check covers fleet-active-queue + worktree mtime; this observation adds shared-surface artifact scanning as a third evidence surface for doc-production work patterns.
• ORA-2026-0014 (identity parity gap) — related cross-surface identity risk, covering boot-surface drift across machines. ORA-2026-0032 is the intra-machine analog: identity collision between two sessions on the same machine that both passed their boot-time checks honestly.
• ORA-2026-0064 (Claude session cron-queue collision) — related but structurally distinct. ORA-2026-0064 is single-session message-queue coalescing; ORA-2026-0032 is multi-session identity-space collision. Both are blind spots in the current fleet-observability model.