[BUG] CREATE TABLE workspace migration silently recorded but not executed — crashes on v1.2.17 upgrade

Root Cause (resolved)

This was caused by running a forked dev build (feature/agent-teams) against the production database on both affected machines. The dev build wrote the workspace migration with a different timestamp (1772134200000) than the official release (1772056728000). Due to a known Drizzle migration timestamp ordering bug, when the official v1.2.16 release ran, it skipped the workspace CREATE TABLE migration because a newer timestamp was already recorded -- but the table had never actually been created.

This is not a bug in the official OpenCode releases. However, the underlying Drizzle bug means any contributor testing a local build with divergent migration timestamps will silently corrupt their database.

Workaround: Manually create the missing table (see below) or delete the database and start fresh.

Original issue description (outdated -- kept for reference)

Description

After upgrading to v1.2.17, OpenCode crashes on every startup:

Failed to run the query 'ALTER TABLE `workspace` ADD `type` text NOT NULL;'

Root cause: Migration 20260225215848_workspace (CREATE TABLE workspace) was recorded as applied in __drizzle_migrations during v1.2.16 startup but never actually executed. When v1.2.17 tries to ALTER TABLE workspace (migration 20260303231226_add_workspace_fields), it fails because the table doesn't exist.

Why it failed silently: The exact mechanism is still under investigation. The initial hypothesis was that PRAGMA foreign_keys = ON (set before migrations in db.ts) might cause the CREATE TABLE with a FK constraint to fail silently. However, as discussed in the comments, SQLite FK enforcement only applies to DML operations, not DDL -- so this likely does not explain the failure. The actual cause may be related to how Drizzle's migrator handles errors or how it interacts with databases that have accumulated data over multiple prior versions.

Reproduced on two machines:

Machine	Chip	Result
Mac Studio	Apple M2 Max	Silent migration failure on v1.2.16, crash on v1.2.17
MacBook Pro	Apple M3 Max	Silent migration failure on v1.2.16, crash on v1.2.17

Both machines show the same DB state: migration hash recorded in __drizzle_migrations, but workspace table does not exist. Both databases were built up over several weeks (v1.2.13 through v1.2.15) with real data before hitting v1.2.16.

Additional observation: OpenCode CLI v1.2.15 (installed via Homebrew on the MacBook Pro) still starts fine because it predates the workspace migration entirely (only ships 3 migrations). The bug is only triggered when upgrading through versions that include migration 20260225215848_workspace.

Evidence from DB (MacBook Pro):

__drizzle_migrations: 5 entries (including workspace migration timestamp) -- all "applied"
workspace table: does not exist
session table: has workspace_id column (migration tweak: glob should be able to read certain hidden files/dirs #5 succeeded -- simple ALTER, no FK)
All other data intact (sessions, messages, projects)

Log timeline (MacBook Pro):

Date	Version	Bundled Migrations	Result
2026-02-26	v1.2.13	3	OK
2026-02-27	v1.2.15	3	OK
2026-03-03	v1.2.15	3	OK
2026-03-04 10:35	v1.2.16	5	No error logged, but `workspace` table not created
2026-03-04 16:01	v1.2.17	6	Crash: `ALTER TABLE workspace` fails

Migration #4 SQL (20260225215848_workspace/migration.sql):

CREATE TABLE `workspace` (
    `id` text PRIMARY KEY,
    `branch` text,
    `project_id` text NOT NULL,
    `config` text NOT NULL,
    CONSTRAINT `fk_workspace_project_id_project_id_fk`
        FOREIGN KEY (`project_id`) REFERENCES `project`(`id`) ON DELETE CASCADE
);

Workaround: Manually create the table, then start opencode:

cp ~/.local/share/opencode/opencode.db ~/.local/share/opencode/opencode.db.bak
sqlite3 ~/.local/share/opencode/opencode.db "CREATE TABLE \`workspace\` (\`id\` text PRIMARY KEY, \`branch\` text, \`project_id\` text NOT NULL, \`config\` text NOT NULL, CONSTRAINT \`fk_workspace_project_id_project_id_fk\` FOREIGN KEY (\`project_id\`) REFERENCES \`project\`(\`id\`) ON DELETE CASCADE);"
opencode

Suggested fix: Verify DDL execution before recording the migration hash, or add a pre-migration check that detects missing tables whose hashes are already recorded and re-runs them.

Plugins

None

OpenCode version

v1.2.17 (crash) -- silent failure occurred during v1.2.16

Steps to reproduce

Fork the repo and build a local dev build with divergent migration timestamps
Run the dev build against a production database -- migrations are recorded with different timestamps
Upgrade to official v1.2.16 -- Drizzle skips workspace migration (known timestamp ordering bug)
Upgrade to v1.2.17 -- crash on startup

Screenshot and/or share link

Operating System

macOS 15.x (Apple Silicon) -- reproduced on Mac Studio (M2 Max) and MacBook Pro (M3 Max)

Terminal

zsh (Homebrew Cask install)

@flitzrrr

I am looking into this, we've had a couple problems with our migrations, but I'm unable to reproduce it so far. I installed 1.2.15, created a few sessions, installed 1.2.16, and it migrated fine (the workspace table was created). That means installing 1.2.17 worked as well.

I don't know why the foreign key would cause any problems with the migration; we don't fill it with any data yet. So there's no idea for it to fail on.

@flitzrrr do you have a way to reproduce this?

When v1.2.17 tries to ALTER TABLE workspace (migration 20260303231226_add_workspace_fields), it fails because the table doesn't exist.

@jlongster

@jlongster thanks for looking into this.

I agree that the FK hypothesis may not hold -- CREATE TABLE with a FK constraint should not fail due to PRAGMA foreign_keys = ON since FK enforcement only applies to DML, not DDL. So something else is going on.

Key fact: this is deterministic, not transient. The identical failure occurred on two completely separate machines (Mac Studio M2 Max, MacBook Pro M3 Max) with identical symptoms: 5 migration hashes recorded in __drizzle_migrations, but no workspace table in sqlite_master. This rules out disk issues, sleep/power events, or database locking as the cause.

What may differ from your test setup: Both of my databases were not freshly created. They accumulated real data over several weeks across versions v1.2.13 through v1.2.15 before hitting v1.2.16. The databases had 9 projects, 44 sessions, 1400+ messages, and 6500+ parts at the time of the failed migration. If you tested with a freshly-created database on v1.2.15 and immediately upgraded, that may explain why you cannot reproduce it.

Pre-fix database state (from backup):

__drizzle_migrations -- 5 entries, all recorded:

hash | created_at
(empty) | 1769552633000  (2026-01-27 22:23:53 UTC)
(empty) | 1770830228000  (2026-02-11 17:17:08 UTC)
(empty) | 1770993676000  (2026-02-13 14:41:16 UTC)
(empty) | 1772134200000  (2026-02-26 19:30:00 UTC)  <-- workspace CREATE TABLE
(empty) | 1772228279000  (2026-02-27 21:37:59 UTC)  <-- session ALTER (workspace_id)

Tables present in sqlite_master (no workspace):

__drizzle_migrations, control_account, message, part, permission,
project, session, session_share, team, team_member, team_message,
team_task, todo

Note: the session table does have the workspace_id column (migration #5 succeeded -- it was a simple ALTER TABLE, no FK involved).

I can provide the following to help reproduce:

A sanitized reproduction database -- I can create a copy with all user data (messages, sessions, parts) stripped out but the schema, migration state, and project stubs preserved. This would let you run the v1.2.17 migration against it and see it fail.
The raw schema metadata -- the full sqlite_master dump and __drizzle_migrations contents from the pre-fix backup, which I have included above.

Let me know which would be most helpful.

Thank you for offering that!

With it being in that state, it makes sense for 1.2.17 to fail. Ideally what I'd get is a db that will reproduce the failure when we run 1.2.16.

I'm still having a hard to reproducing it. I just took my own database, which has a lot of sessions, projects, etc, and removed the migrations. I deleted the migrations from the migration table, and then revert my schema to undo them (deleted the workspace table etc). I then ran 1.2.16. It worked fine and the workspace table got created:

I believe that something went wrong in your filesystem with your particular db... if you want, you can send over your db and I'll try the same thing above that I did with mine. If that fails, not sure what else we can do

I'll keep an eye out for anyone else reporting this too, so far you're the first one

@jlongster

@jlongster I have attached a sanitized reproduction database (all user data stripped, project paths and IDs anonymized, 3KB zipped). This database was taken from my MacBook Pro before applying the workaround.

opencode-sanitized.db.zip

To reproduce: place opencode-sanitized.db at ~/.local/share/opencode/opencode.db (remove any existing -wal and -shm files first), then run v1.2.17. It will crash with:

Failed to run the query 'ALTER TABLE `workspace` ADD `type` text NOT NULL;'

I verified this on my end -- the sanitized DB reproduces the crash consistently.

One thing I noticed: your 4th migration timestamp is 1772056728000, mine is 1772134200000. These differ, which could mean the workspace migration SQL was modified between builds. If I received a different version of that migration than what you are testing with, that could explain why your reproduction attempts succeed while mine fail deterministically.

Re: filesystem theory: I would not expect a filesystem-level issue to produce identical failures on two separate machines (Mac Studio M2 Max and MacBook Pro M3 Max) with identical database states. Both had 5 hashes recorded and no workspace table.

It makes sense that 1.2.17 would fail given this db. What we need to figure out is what the original migration in 1.2.16 didn't apply.

I took your db and dropped the session table and recreated it without workspace_id, and deleted the two newer migrations in it, and then ran 1.2.16 and it was able to apply the two migrations (which created the workspace table and modify session)

The migration will always fail 1.2.17 if the workspace table doesn't exist. The migration in 1.2.16 should have created it. Good point about the migration timestamps, that is weird. I am reinstall OpenCode from scratch for each of these versions from npm so it should be coming with the same migrations everybody gets.

Did you ever run a beta build, or from source? That might be the issue: it inserted a migration from some development work, and right now we are aware of a bug in drizzle where if the timestamp is newer than a migration that isn't applied, it does not apply that migration. The timestamp is likely the issue, however you ended up with that timestamp

@jlongster

@jlongster you nailed it -- the dev build is the cause.

Root cause confirmed: I forked the repo and was developing a feature/agent-teams branch locally. I built and ran that dev build against my production database on both machines (Mac Studio and MacBook Pro). This build wrote the workspace migration with timestamp 1772134200000 into __drizzle_migrations. When the official v1.2.16 release came with the same migration but timestamp 1772056728000 (earlier), the known Drizzle bug caused it to be skipped -- because a newer timestamp was already recorded.

Evidence from this machine (MacBook Pro):

Dev build binary still present:

~/git/opencode/packages/opencode/dist/opencode-darwin-arm64/bin/opencode
Built: 2026-03-01 01:02
Version: 0.0.0-feature/agent-teams-202603010001

The binary was symlinked into PATH:

~/.local/bin/opencode -> ~/git/opencode/packages/opencode/dist/opencode-darwin-arm64/bin/opencode
Symlink created: 2026-03-03 21:07

Git repo checkout:

~/git/opencode/ @ feature/agent-teams branch
HEAD: 482920354 "fix(agent-teams): align theme tokens + use real LLM model picker"

Migration timestamp comparison:

Dev build (feature/agent-teams):  1772134200000  (2026-02-26 19:30:00 UTC)
Official release (v1.2.16):      1772056728000  (2026-02-25 21:58:48 UTC)

The dev build timestamp is ~21 hours newer. When v1.2.16 ran, Drizzle saw that a migration with a newer timestamp was already recorded and skipped the workspace CREATE TABLE -- but the dev build had only recorded the hash, not actually created the table (or created a different version of it that was later dropped).

Sequence of events:

Ran feature/agent-teams dev build -- wrote migration hash with timestamp 1772134200000
Upgraded to official v1.2.16 -- Drizzle skipped workspace migration due to known timestamp bug (newer hash already present)
Upgraded to v1.2.17 -- ALTER TABLE workspace failed because the table was never created

Conclusion: The trigger was running a forked dev build against the same database that the official releases use. However, the underlying issue is the known Drizzle migration timestamp ordering bug -- it silently skips migrations instead of raising an error, which makes this kind of scenario fail in a way that is very hard to diagnose. Any contributor testing a local build will hit this if the migration timestamps diverge.

I will update the issue description to reflect this. Thanks for the quick investigation and the pointer to the Drizzle timestamp bug -- that was the key insight.

Thanks for the detailed issue! glad we could resolve this, and this will be resolved in the next drizzle release so this don't be an issue in the future

Navigation Menu

Repository navigation

[BUG] CREATE TABLE workspace migration silently recorded but not executed — crashes on v1.2.17 upgrade #16026

Root Cause (resolved)

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG] CREATE TABLE workspace migration silently recorded but not executed — crashes on v1.2.17 upgrade #16026

Description

Root Cause (resolved)

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

jlongster commented on Mar 4, 2026

flitzrrr commented on Mar 4, 2026

jlongster commented on Mar 4, 2026

flitzrrr commented on Mar 4, 2026

jlongster commented on Mar 4, 2026

flitzrrr commented on Mar 4, 2026

jlongster commented on Mar 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions