Imported agent sessions duplicate T3-native threads: import dedup never consults the native thread namespace #10933

What happened

A Claude Code session that T3 Code itself drove appears twice in the thread list: once as the native thread that ran it, and once more as an imported thread created from that same session's on-disk transcript.

The two rows have different ids and different generated titles, so they do not look like duplicates in the UI, but they are the same conversation.

Concrete pair, from the machine that still holds its original database (machine A below):

import:claudeAgent:020e7f00-dce6-406b-8ec6-ed90498945d6
    title: <redacted>

806E5EEB-9001-41FD-8180-79D380604B3E                     (native)
    title: <redacted>
    provider_session_runtime.resume_cursor_json ->
        "resume": "020e7f00-dce6-406b-8ec6-ed90498945d6"

Same underlying Claude Code session. Two threads. 131 sessions are double-represented this way on machine A.

Diagnosis

Two independent places drop the same check, and neither one ever compares a candidate against the native thread namespace.

1. The importer only deduplicates within the import namespace.

apps/server/src/project/AgentSessionImporter.ts builds the thread id from the provider session id, then looks for a pre-existing thread using only that import-namespaced id:

const threadId = ThreadId.make(
  `import:${thread.providerInstanceId}:${thread.providerSessionId}`,
);
const imported = yield* Effect.gen(function* () {
  ...
  const existingThread = yield* snapshots.getThreadDetailById(threadId);
  const existingBinding = yield* directory.getBinding(threadId);

getThreadDetailById is only ever asked about import:claudeAgent:<uuid>. A native thread already driving <uuid> has a completely different thread id, so it is invisible to this lookup. The importer therefore creates a second thread for a session that is already live.

2. alreadyImported is keyed on project path, not on provider session id.

apps/server/src/project/AgentSessionScanner.ts builds candidates from the provider CLIs' on-disk transcripts, then sets the flag from a map keyed on workspace root path:

const importedProjectsByRoot = new Map<string, (typeof shellSnapshot.projects)[number]>();
for (const project of shellSnapshot.projects) {
  const projectRoot = path.resolve(expandHomePath(project.workspaceRoot));
  importedProjectsByRoot.set(normalizeProjectPathForComparison(projectRoot), project);
  importedProjectsByRoot.set(yield* directoryIdentity(projectRoot), project);
}
...
const importedProject =
  importedProjectsByRoot.get(normalizeProjectPathForComparison(entry.path)) ??
  importedProjectsByRoot.get(key);
...
alreadyImported: importedProject !== undefined,

The schema comment in packages/contracts/src/agentSessions.ts agrees with that reading:

"alreadyImported marks candidates that already have an active project rooted at the same path."

So the flag answers "does a T3 project already exist at this directory". AgentSessionScanner.ts contains no occurrence of threads, resume_cursor_json, or provider_session_runtime at all, so it has no way to consult session identity even in principle. A session already running as a native thread is offered as a fresh import candidate with alreadyImported: false.

The durable key needed for both checks is already stored. A native thread's provider_session_runtime.resume_cursor_json carries resume (and sometimes resumeSessionAt), which are the Claude Code session uuids naming the exact transcript files the scanner is reading.

Why #510 does not cover this. Its acceptance criteria already state the right principle:

"Refresh/re-scan deduplicates by provider thread id (or equivalent durable Codex thread identity)"

That criterion prevents re-importing the same session twice within the import namespace. It does not cover a session existing in the native and imported namespaces simultaneously, which is what this report is about.

Why it got much worse across two environments. ~/.claude was migrated to a second Mac, so both machines see overlapping transcript sets. Session counts observed on machine A:

Claude Code sessions on the old Mac : 519
Claude Code sessions on the new Mac : 571   (the 519, plus 52 of its own)
sessions only on the old Mac        : 0

(Counted one level deep with unique session basenames; a recursive count under projects gives a larger number.)

Both machines are connected over T3 Connect. The new Mac's scanner offers all 571 as import candidates, including 141 whose sessions are already arriving as native threads from the other environment. Settled counts diverge as a result: 559 on the new machine against 380 on the old one, for what should be the same set of conversations.

Wiping the T3 database and re-onboarding does not help, because the scanner reads ~/.claude/projects, not the database. Every clean onboard re-offers the same set and rebuilds the same overlap.

Steps to reproduce

1. Run a Claude Code session inside T3 Code so it becomes a native thread. Claude Code writes its own transcript to ~/.claude/projects/<dir>/<uuid>.jsonl.
2. Open the project import flow, or onboard a second environment that can see the same ~/.claude directory.
3. The already-running session is offered as an import candidate, with alreadyImported: false.
4. Import it. The conversation now exists twice, under two ids, with two different generated titles.

Suggested fix. Exclude a transcript from the import candidates, and from the import itself, when a live thread already drives that provider session. Alongside importedProjectsByRoot, the scanner needs a set of provider session ids taken from provider_session_runtime.resume_cursor_json for non-imported threads, and alreadyImported (or a new alreadyLive flag) would be true when the candidate's session id is in that set. The importer's getThreadDetailById check needs the equivalent native-namespace lookup before it creates a thread. Grouping candidates by directory is still right for the project list; the per-session check is what is missing.

Version

Server reports 0.0.40; app bundle is 0.0.41-nightly.20260909.1439. Source citations above were verified against tag v0.0.40 (commit 09e8de9).

Environment

macOS 26.6 (Darwin 25.6.0), Apple silicon, Node v25.9.0. Two environments connected over T3 Connect. Providers in use: claudeAgent, codex.

Evidence

# Run against ~/.t3/userdata/state.sqlite
# NOTE: this must be run on an environment where sessions have actually been
# driven through T3 Code. An environment that only ever imported sessions has
# no native threads, so the join is empty and the query correctly returns 0.

WITH native AS (
  SELECT json_extract(r.resume_cursor_json, '$.resume') AS sid
  FROM projection_threads t
  JOIN provider_session_runtime r USING (thread_id)
  WHERE t.thread_id NOT LIKE 'import:%'
    AND r.provider_name = 'claudeAgent'
    AND json_extract(r.resume_cursor_json, '$.resume') IS NOT NULL
),
imported AS (
  SELECT replace(thread_id, 'import:claudeAgent:', '') AS sid
  FROM projection_threads
  WHERE thread_id LIKE 'import:claudeAgent:%'
)
SELECT COUNT(*) AS double_represented
FROM native JOIN imported USING (sid);

# Machine A (original database, sessions driven through T3 Code):
#   projection_threads: 226 native, 204 imported
#   double_represented: 131
#   Both rows of the example pair are present.

# Machine B (database wiped and re-onboarded with imports only):
#   projection_threads: 176 total, 176 imported, 0 native
#   double_represented: 0
#   Expected: no native threads exist to join against. This says nothing
#   about the bug. The example pair's transcript is still on disk here at
#   ~/.claude/projects/<dir>/020e7f00-dce6-406b-8ec6-ed90498945d6.jsonl
#   while neither thread row exists in the rebuilt database.

Related issues

#510 (closed) states the correct dedup principle in its acceptance criteria, but scopes it to re-scans within the import namespace. It does not cover a session that is simultaneously native and imported, so this is not a duplicate and #510 does not need reopening.

Fix applied or workaround

None. No writes were made to the database. Diagnosis was performed against a read-only copy.

Filed by

claude (opus-5) via t3 triage