I provided feedback under 8b0dc175-92a9-48b0-b546-094f940712d2 but have not heard from anybody for 2 days.
Please acknowledge receipt
What is your specific issue? Please describe it here, and I will take a look
# Support ticket: Quest → Qoder migration only imports 2 of 78 sessions
**Product:** Qoder (new release, `C:\Users\Owner\AppData\Local\Programs\Qoder`)
**Source product:** Qoder IDE (Quest) v1.32.2 (`C:\Users\Owner\AppData\Local\Programs\Qoder IDE`)
**Platform:** Windows 11 (10.0.26200), x64, projects in WSL Ubuntu-24.04
**Date:** 2026-10-08
## Summary
I ran the built-in data import (“Import from Quest”) in the new Qoder. It imported **1 session** (`Where am i`) from the old Quest IDE and 6 sessions from QoderWork — but my Quest IDE contains **~2 years of history: 76 agent quests across 12 workspaces** (dVE 22, elm 18, sysml 13, dveracity-web 11, openfootprint 3, OGMP-IMEO 2, pact 2, dv 1, OSDU 1, rtdip 1, 3commas 1, pact-conformance-test-service 1). Re-running the import cannot find more.
## Root cause (with evidence)
The `quest` migration adapter is configured to read only the old app’s local session store:
```
{sourceProduct:“quest”, adapter:“quest”,
databaseRelativePaths:[[“Qoder”,“SharedClientCache”,“cache”,“db”,“local.db”]], …}
```
On this machine `Roaming\Qoder\SharedClientCache\cache\db\local.db` contains only **2 sessions** — the old Quest IDE apparently wrote almost nothing there.
The actual quest history is stored in the old app’s global storage SQLite:
- `C:\Users\Owner\AppData\Roaming\Qoder\User\globalStorage\state.vscdb`
-
ItemTable key `aicoding.questTaskListSnapshot` (~95 KB JSON): full inventory of **76 tasks** (id, name/title, status, created/finished timestamps, sourceBranch, query, executionSessionId, workspaceUri, questType, agentClass)
-
ItemTable keys `lingma.chat.localHistory..quest`: Quest History panel entries (user prompts + image attachments, ~81 MB total across sysml/dVE/elm/openfootprint)
-
`C:\Users\Owner\AppData\Roaming\Qoder\User\workspaceStorage\\workspace.json` maps workspaceHash → folder path
- Migration ledger confirming the gap: `C:\Users\Owner\AppData\Roaming\com.qoder.app.stable\sessionMigration.sqlite`
-
`import_job`: source_product `quest`, status `completed`, **total: 1**
-
`candidate_snapshot_meta`: quest session_count **1**, qoderWork session_count 6
The new app’s binary contains **no reference** to `state.vscdb`, `localHistory`, or `questTaskListSnapshot`, so the importer structurally cannot see the real data.
## Impact
Users with substantial Quest history lose access to it after migrating: quests do not appear in the new Qoder, and the old IDE is the only place the history remains readable.
## Requested fix
Extend the `quest` import adapter to also read, from the old installation:
1. `Roaming\Qoder\User\globalStorage\state.vscdb` → `aicoding.questTaskListSnapshot` (quest metadata: title, status, timestamps, branch, prompt)
2. `lingma.chat.localHistory..quest` entries (prompts + attachments), correlated via `executionSessionId`, with workspaceHash → folder resolved through `workspaceStorage\\workspace.json`
3. Optionally `workspaceStorage\\chatEditingSessions\task-*\state.json` (file-edit recovery state)
Imported sessions will necessarily be prompt/metadata-only on the user side (assistant turns were server-side in Quest and are not locally recoverable) — even so, having the 76 quests listed with their prompts, dates, and workspaces in Qoder would fully solve the migration.
## Attachments available on request
- `questTaskListSnapshot.json` (full 76-task inventory)
- `sessionMigration.sqlite` (import_job / candidate_snapshot evidence)
- `state.vscdb` backup (166 MB) — contains prompts and attachments
Hi Austin, Any progress? I have 3 days to do the import data as the deadline is October 15th and do not want to leave this till the last minute
I send feedback again: fb814c1e-71c4-4946-a041-53f57cf518bb
using the button as you described how to submit a bug.
Hi Austin, some feedback to your engineering: I used the latest release of Qoder
Version 0.4.4
Commit 169d3c
Build Date 2026-10-09 Early morning
Previously the below prompt in fb814c1e-71c4-4946-a041-53f57cf518bb adviced me to report a bug
The new version solved the problem. See below what it found as root cause and please confirm with your engineers that Qoder solved this correctly and I will not have problems going forward
Prompt:
Please can you help me with the migration from Quest to Qoder. We are now in Qoder the latest release, but I do not see my Quests. I normally start qoder from Ubuntu as “qoder .” The attachment is my current QUEST IDE view and as you can see in the second attachement that is QODER. I did the data imports, but it had only a few tasks. I have been using Qoder for almost 2 year. So I expected a lot more that needs to be imported. Can you fix?
After about 2 hours (some wait time due to me still running Quest IDE)
Root cause
The importer was reading the merged database correctly — but it silently drops any session whose workspace path doesn’t exist on this PC (fs.statSync on project_uri). All 79 of your WSL-hosted quests point to /home/ajvdvoort/..., which doesn’t exist from Windows’ perspective, so only the one Windows-path quest (“Where am i”) survived enumeration.
What I changed
- Rewrote all 536
project_urivalues in the merged DB from/home/ajvdvoort/...to//wsl.localhost/Ubuntu-24.04/home/ajvdvoort/...(a UNC path Windows can actually see — I verified the app’s own Node runtime stats it correctly, and all 79 project directories resolve). - Cleared the stale 1-row discovery snapshot in
sessionMigration.sqliteso the next check rescans fresh. - Fresh backup of the pre-edit DB at
local.db.bak-uri-20261013; your WSL source DB is untouched.
There were 11 that were not imported. Below fixed that:
68 of 79 imported cleanly — nice. The 11 failures were all worktree sessions: the old IDE ran them in git worktrees, and the new Qoder tries to recreate those as live managed worktrees. That failed because the worktree paths inside the sessions’ extra metadata were still WSL paths — and the “successful” version of that path would have created new *-migration branches and worktree checkouts inside your real git repos (openfootprint, dveracity-web, elm, sysml, pact, dVE), which is a lot of mutation for 2-year-old history.
So I took the safe route: neutralized the worktree config on those 11 sessions. They’ll now import as plain sessions under their main workspace — transcripts identical, zero changes to your repos. The extra metadata is also rewritten to the UNC paths for consistency. Fresh backup: local.db.bak-extra-20261013.
I will be testing the imported data in the coming days. Please confirm the old QUEST IDE quests will not be removed until I say so and that the new Quests live somewhere else and I can continue
Regards
AJ