SESSION_POPULATION_BINDING_MISMATCH when reviewing from inside the target workspace (Claude Code)

[viper3-o]

Summary

harness evidence-bundle fails deterministically with SESSION_POPULATION_BINDING_MISMATCH when the review is run from a Claude Code session whose own transcript lives in the target workspace's session directory. Both the sessionEvidence lane and the lead lane become unavailable, so the whole run stops per the skill contract.

Environment

• better-harness 0.4.0 (marketplace clone @ 446bb27, 2026-07-31)
• Host: Claude Code (platform claude)
• OS: macOS (Darwin 25.3.0, arm64)
• Node: v22.23.1

Reproduction

1. Open Claude Code in a workspace that has in-window session history (in my case 131 eligible sessions / 527 task episodes in the last 30 days).
2. Invoke /better-harness, which runs:

node scripts/better-harness.mjs harness evidence-bundle \
  --platform claude --workspace <target> --language zh \
  --depth normal --since 2026-07-01 --until 2026-07-31 --format json

3. Bundle comes back status: failed:
   • lanes.sessionEvidence: unavailable, SESSION_POPULATION_BINDING_MISMATCH
   • lanes.projectHarness: available
   • lanes.agentCustomize: available
   • lead: unavailable, SESSION_POPULATION_BINDING_MISMATCH

Reproduced 4/4 times, across both normal and quick depths and different --until values (2026-07-31 and 2026-08-01).

What I checked

• session-analysis facts with the same window works fine standalone (131 eligible sessions, 527 task episodes, candidates emitted) — the underlying session data is readable.
• Re-running the analyzer with the bundle's own options (--selection all-eligible --limit 5 --episode-limit 5) returns eligibleSessions: 131, selectedSessions: 131.
• Running the same bundle command against a workspace with zero sessions succeeds (sessionEvidence available, eligibleSessions: 0). So collection only breaks when real in-window sessions exist.

Hypothesis

The reviewing session itself is an active session inside the scanned directory (~/.claude/projects/<workspace>/). The frozen population count and the analyzer's all-eligible count appear to disagree over the active session, tripping the binding check in scripts/harness-analysis/evidence-bundle/session-evidence.mjs (eligibleCount !== population.binding.eligible.count || selectedCount !== population.binding.eligible.count).

Expected

Reviewing a workspace from a live session inside that same workspace is the primary usage path for the Claude Code host, so the population freeze and the analyzer should agree on how the active session is counted (both include it or both omit it), rather than failing closed.

Workaround (unverified)

Run the review from a Claude Code session in a different directory, targeting the workspace to review — consistent with the hypothesis that the in-workspace active session is what trips the check.

[viper3-o]

Update: original hypothesis disproven — real root cause is an internal off-by-one

Following up with more digging. The "active session in the target dir" hypothesis in the original report is wrong. I reproduced the failure from a fresh Claude Code session running in /tmp (different cwd entirely), still targeting the autoclaw workspace — same SESSION_POPULATION_BINDING_MISMATCH. So it is not about the reviewer living in the scanned directory.

What actually diverges

The bundle's own diagnostics show the two internal counts disagree by exactly one:

"sessionPopulationBinding": {
  "status": "conflict",
  "population": {
    "omission": {
      "exactIdentityAvailable": false,
      "activeSessions": 0,
      "recencyInference": "disabled-frozen-until"
    },
    "eligible": { "count": 130, ... }
  }
}

• Frozen population (freezeSessionPopulation → prepareFactsSessionInventory): 130 eligible
• Analyzer (session-analysis facts --selection all-eligible --limit 5 --episode-limit 5): 131 eligible

The binding check (session-evidence.mjs) requires eligibleCount === population.binding.eligible.count, so 131 ≠ 130 throws.

Notes

• activeSessions: 0 — the population did not detect/omit an active session, so the off-by-one is not active-session handling.
• exactIdentityAvailable: false is just a policy-fingerprint flag (Boolean(excludedSessionId), false because no exclusion id was supplied) — not the cause, just a symptom that gets surfaced.
• session-analysis facts (the lenient diagnostic path) reads all 131 sessions and emits candidates fine; only the strict population-freeze path drops 1.
• 132 physical .jsonl files exist in the project session dir within the window; one of them appears to be accepted by the analyzer parser but rejected by the population-freeze parser.

Suspect

The two session-parsing paths (prepareFactsSessionInventory vs the session-analysis facts collector) disagree on exactly one session file in this workspace — likely a record the strict parser rejects (e.g. an oversized/malformed line) that the lenient one skips/resumes. A deterministic parser disagreement, not a timing race or an active-session issue.

Reproducibility

Deterministic, across normal/quick depth, across --until values, and across the reviewer's cwd (in-workspace and /tmp). Reproduced 5+ times.

[viper3-o]

Correction #2: malformed-line hypothesis also disproven

Ignore my earlier "oversized/malformed line" guess — I scanned all 132 .jsonl files in the project session dir with a strict per-line JSON parser: 0 files have any unparseable line. Every line in every file is valid JSON.

So the 130 (population freeze) vs 131 (analyzer) divergence is a pure filtering disagreement between prepareFactsSessionInventory and the session-analysis facts collector over fully-valid session files — most likely a session-validity or workspace-binding rule (e.g. cwd/path match) where the strict path drops one session the lenient path keeps. Worth adding debug logging to freezeSessionPopulation's prepareFactsSessionInventory to see which sessionId it drops.

Summary of what's ruled out so far:

• ❌ Active session living in the scanned dir (reproduces from /tmp cwd)
• ❌ Malformed/incomplete JSONL lines (all 132 files clean)
• ❌ --until in the future / window edge (reproduces with default window and past --until)
• ✅ Deterministic off-by-one: population freeze = 130, analyzer = 131

[phodal]

@viper3-o PR ?