[Bug] SQLite search results lose the SessionHeader origin field

[GCSimba]

Current-version update — 2026-10-07

Rechecked on 2026-10-07 against the newest public release, 0.2.1-alpha.1, and upstream master at 5badb15009ae1756c3afe0ae0cef1faafc290ccc. The search-result origin fix remains applicable. The owning search-header file passed 7 cases on Windows and separately on Linux. Derived schema 8→9 rebuilds; canonical Session JSONL is unchanged. All five product commits are preserved in the published current-baseline integration; both the full build and full lint passed.

Current patch index and verification limits. No all-checks-pass, upstream acceptance or released-fix claim is made. This update is AI-assisted with Codex; the published commits retain its co-author.

The original report and its verification history are preserved below.

---

Summary

On master at 5badb15009ae1756c3afe0ae0cef1faafc290ccc, SQLite-backed searchSessions() and searchEvents() omit SessionHeader.origin, although listing and exact reads preserve it. This affects both live and persisted search rows.

I did not find an equivalent public report in the searches performed for this audit. The report concerns search-result metadata, not a claim that the current Web UI necessarily misclassifies sessions.

Reproduction and observed result

Create a session whose header includes origin: 'subagent', a parent Session id, and a searchable user message. Compare the returned header from listSessions(), searchSessions(), and searchEvents().

The pre-fix probe ran once with a live session and once with a cold JSONL-persisted session. In both modes, these selected fields were returned (other header fields omitted here):

{
  "listed": {
    "id": "audit-child",
    "parentSession": "audit-parent",
    "origin": "subagent"
  },
  "searched": {
    "id": "audit-child",
    "parentSession": "audit-parent"
  },
  "searchedEvents": {
    "id": "audit-child",
    "parentSession": "audit-parent"
  }
}

Both pre-fix regressions failed. A parent id is not a replacement for origin: ordinary forks also have parents.

Root cause and patch

The derived persisted_sessions table and connection-owned live_sessions table do not store origin. Their INSERT bindings, search selections, and header reconstruction therefore cannot reproduce the original metadata.

The patch stores nullable origin in both row types and preserves it through selections, reconstruction, and header comparison. Roots and ordinary forks continue to omit the field when it was absent.

The derived SQLite schema intentionally advances from 8 to 9. Recognized older derived indexes rebuild from authoritative Session sources; unrelated or unknown databases remain refused. Canonical Session JSONL, Session format, public TypeScript types, search API, query semantics, wire values, dependencies, and package exports remain unchanged. Existing indexes incur a one-time rebuild.

• Bug-specific commit
• Branch containing the four independent commits
• Complete regression and schema-8 rebuild fixture

Verification

The regression matrix covers live and persisted subagents, ordinary forks, and roots through both search methods. A real older index fixture removes the new column and sets schema version 8; reopening rebuilds it, retains origin across another reopen, and leaves the canonical JSONL byte-identical.

On Ubuntu 24.04 under WSL2, Node 24.19.0 and pnpm 11.7.0, this combined-branch command passed 402 tests with four unchanged platform-specific skips:

corepack pnpm exec vitest run packages/fs/fs-local/tests/fsio.spec.ts packages/fs/fs-local/tests/filesystem.spec.ts packages/fs/tool-str-replace-editor/tests packages/session-query/session-query-sqlite/tests packages/util/native-command/tests packages/host/open-in-app/tests --coverage --coverage.include=packages/fs/fs-local/src/fsio.ts --coverage.include=packages/fs/tool-str-replace-editor/src/index.ts --coverage.include=packages/session-query/session-query-sqlite/src/index.ts --coverage.include=packages/session-query/session-query-sqlite/src/schema.ts --coverage.include=packages/util/native-command/src/desktop-entry.ts

Both changed SQLite modules, and all five modified production modules across the branch, reached 100% statements, branches, functions, and lines. Windows owning suites also passed. Full build and type-aware lint passed. The normal pre-push hook also ran the full pnpm run typecheck successfully before publication to the fork. Counts are combined-branch local evidence; no upstream CI run is claimed.

The full hygiene aggregate is not claimed green: 16 unchanged vendor rescope residues were reproduced on the pristine baseline. The earlier doc-sync aggregate hit a default-heap OOM; 41 other checks passed, and the graph check passed separately with a 4-GB heap. The updated bilingual corpus passed independently.

Distinction from adjacent reports

#5486 describes the mention picker admitting worker sessions because its candidate filter only excludes self. Its proposed fix filters parented sessions. This is a different operation and defect: SQLite FTS result reconstruction loses an explicit header field, including when a caller directly uses the search APIs. This patch neither changes mention candidates nor infers subagents from parenthood.

This patch does not add an origin search filter, change ranking, or change canonical persistence. Actual macOS execution and a visual UI workflow were not part of this verification.

The patch is offered as a cherry-pickable fork commit under the current contribution policy. Audit, implementation, and local verification were AI-assisted with Codex; the commit includes Co-authored-by: Codex <noreply@openai.com>.

[luoyukun3-oss]

Confirmed on the released line as well.

In @deepseek-ai/dsh-session-query-sqlite/lib/index.js (0.1.7-rc.2) the string origin appears
exactly once, and that occurrence is inside a comment — nothing in searchSessions() (:537) or
searchEvents() (:558) reads or forwards it. The non-SQLite @deepseek-ai/dsh-session-query
package contains no origin reference at all.

So the field is dropped on the search path in the published version too, which fits your
live-and-persisted result. And as you already note, this is a metadata gap in search results —
not evidence that the Web UI misclassifies sessions.