The migration log message previously pointed users to docs/reference/configuration.md for the new LSP config location, but that doc section still showed the obsolete plugin-level 'lsp' block. A user following the guidance would re-add the same 'lsp' key, see it stripped again on next startup, and never reach a usable config.\n\nFix both sides: rewrite the log message so it is self-contained (states the new path .opencode/lsp.json and the consumer directly) and rewrite the LSP section in docs/reference/configuration.md to describe the actual current architecture (LSP served by the 'lsp' MCP server, reading server map from .opencode/lsp.json via LSP_TOOLS_MCP_PROJECT_CONFIG, schema lives in packages/lsp-tools-mcp).\n\nVerification: bun test src/shared/migration/ -> 26/26 pass. bun run typecheck -> exit 0. Manual probe -> migration still strips lsp from both in-memory and persisted file.
The lsp config block was removed from OhMyOpenCodeConfigSchema when LSP tools were migrated from native plugin tools to the lsp tier-1 MCP server (packages/lsp-tools-mcp). Zod v4 strips unknown keys silently on safeParse, so a v3-era oh-my-opencode.jsonc with 'lsp': { typescript: { command: ... } } continues to live in the file unchanged while doing absolutely nothing. The user reporting #4225 saw their custom LSP servers stop working with zero indication that the configuration site moved.\n\nAdd a migrator that removes the orphan lsp key during migrateConfigFile, mirroring the existing omo_agent -> sisyphus_agent migration immediately above and the 'Removed obsolete hooks from disabled_hooks' precedent below. A single log line records the configPath and the list of dropped server keys so the user has a paper trail in oh-my-opencode.log, and needsWrite is flipped so the cleanup persists to disk (with a timestamped backup) the next time the plugin loads.\n\nReproduction (clean upstream/dev, BEFORE fix):\n needsWrite=false\n inMemory.lsp=<original block, kept>\n persisted.lsp=<original block, kept>\n\nVerification (AFTER fix):\n needsWrite=true\n inMemory.lsp=undefined\n persisted.lsp=undefined\n\nbun test src/shared/migration/ -> 26/26 pass (24/24 pre-existing + 2 new regression tests). bun run typecheck -> exit 0.
`openai/gpt-5.3-codex` is the codex-series powerhouse still recommended
in docs/guide/agent-model-matching.md and listed in the default
fallback chain in docs/reference/configuration.md, not a deprecated
alias for `gpt-5.4`. The migration entry silently rewrote any user
config that picked `gpt-5.3-codex` for its token efficiency, sending
agents to a non-codex model on every startup.
Drop the bogus mapping from MODEL_VERSION_MAP and add a regression
test that explicit `gpt-5.3-codex` selections (including in nested
fallback_models) survive `migrateModelVersions`. Users already
auto-migrated previously can revert to `gpt-5.3-codex` by hand and it
will now stick on subsequent loads regardless of the sidecar history.
Now that oracle, hephaestus, and the deep category ship gpt-5.5-native
prompts and default to gpt-5.5 in their fallback chains, user configs
that pin openai/gpt-5.4 should follow the same upgrade on next load.
The existing migration pipeline (migrateModelVersions) picks this up
automatically from MODEL_VERSION_MAP, records the upgrade in the
sidecar file to stay idempotent, and leaves gpt-5.4-mini / -mini-fast
/ -nano alone since those cost-tier variants are intentional picks
and do not have direct gpt-5.5 counterparts yet.
Addresses review feedback on #3486:
1. claude-thinking-legacy-alias now matches both claude-opus-4-6-thinking
and claude-opus-4-7-thinking, canonicalizing both to claude-opus-4-7.
The previous diff retargeted the regex to 4-7 only, which dropped
backward compatibility for users still pinned to the 4-6 thinking
suffix.
2. MODEL_TO_CATEGORY_MAP keeps the claude-opus-4-6 to unspecified-high
entry alongside the new 4-7 entry. The map is order-independent from
MODEL_VERSION_MAP, so preserving the 4-6 key avoids relying on a
specific migration ordering for legacy agent configs.
3. Fix stale 'Claude Opus 4.6' labels and BDD test comments that the
sed-based bump missed.
MODEL_VERSION_MAP now chains the legacy claude-opus-4-5 entry straight
to claude-opus-4-7 and adds an explicit claude-opus-4-6 to 4-7 bump
path, letting existing user configs upgrade on next load without an
intermediate 4-6 stop.
MODEL_TO_CATEGORY_MAP picks up claude-opus-4-7 as the canonical
unspecified-high model (prior 4-6 entry is covered by the chained
version map above, so legacy hardcoded configs still resolve).
Migration tests rewritten to reflect the chained 4-5 to 4-7 behavior
and the new 4-6 to 4-7 bump path, including the sidecar-union
scenario.
- shell-env: detect Git Bash via MSYSTEM env var when SHELL is unset (#3366)
On some Git Bash installations SHELL is not set but MSYSTEM (MINGW64/MSYS)
is always present. Check MSYSTEM before PSModulePath to avoid emitting
PowerShell syntax in bash shells.
- session-state: resolve legacy agent names in resolveRegisteredAgentName (#3272)
Historical sessions stored agent names like 'Sisyphus (Ultraworker)' which
don't match the current registered format. Fall back to getAgentConfigKey
for legacy/parenthesized name resolution before returning the raw name.
- config-migration: skip backup when file content is unchanged (#3222)
Compare serialized config with existing file content before creating a
timestamped .bak file. Only create backup when the on-disk content
actually differs from the migrated content.
Old sessions and configs reference agent names in parenthesized format
like 'Sisyphus (Ultraworker)' and 'Atlas (Plan Executor)' which failed
to map during migration. Added entries for all six core agents.
🤖 Generated with OhMyOpenCode assistance
https://github.com/code-yeongyu/oh-my-opencode
Addresses Cubic review: configs without prior _migrations now get the
full migration set written to config as fallback when sidecar write
fails, preventing migration tracking loss.
Users who auto-migrated from `openai/gpt-5.3-codex` to `openai/gpt-5.4`
and then reverted their config back to `gpt-5.3-codex` by hand had the
migration re-apply on every startup in an infinite loop. Discord bug
report pointed at the exact symptom: "i deleted the migrations and they
kept coming back".
The old migration tracking lived on the config body itself as a
`_migrations` string array. The skip-already-applied check relied on
the user not touching that field. But users hit by the unwanted
migration naturally reached for the JSON file to roll their model back,
and the natural human reaction to an incomprehensible internal field
next to their config is to delete it. That wiped the migration memory
and let the same migration re-apply at the next startup.
This PR introduces a sidecar state file that lives next to the config
as `<configPath>.migrations.json` and tracks applied migrations
outside the user's hand-editable config body. The migration pipeline:
1. Reads applied migrations from BOTH the sidecar AND the legacy
in-config `_migrations` field, unioning them. This keeps old
configs that still carry `_migrations` working without forcing
a reset.
2. Writes the updated migration set to the sidecar, never to the
config body.
3. Strips the legacy `_migrations` field out of the config body on
the first write after the sidecar takes over. Users stop seeing
the mystery internal field in their own config from that point
forward.
If the user also deletes the sidecar (explicit fresh-start gesture)
the migrations run again - that is intentional.
Tests (TDD, all new tests written before implementation):
- src/shared/migration/migrations-sidecar.test.ts - 11 unit tests
covering read/write/round-trip, malformed-payload resilience,
parent-directory creation, sorted output for stable diffs, and
non-string entry filtering.
- src/shared/migration.test.ts - 6 new integration tests under the
"migrateConfigFile with migration tracking via sidecar" block
covering: no-op path, sidecar-only write, sidecar skip after user
revert, legacy _migrations mirroring + strip, sidecar + legacy
union with dedupe, and partial-history append. Existing
"preserves existing _migrations and appends new ones" test was
rewritten to assert the new sidecar-based contract.
- Also fixes a latent test-hygiene bug: the shared
/tmp/nonexistent-path-for-test.json config path used by many
migrateConfigFile tests did not clean up its companion sidecar
between tests, letting state from one test bleed into the next.
Added afterEach that unlinks the sidecar.
Verified:
- bun test src/shared/migration/ -> 11 new sidecar tests pass
- bun test src/shared/migration.test.ts -> 82 pass, 0 fail
- bun run typecheck -> clean
- bun run script/run-ci-tests.ts -> 4458 pass, 0 fail (full suite)
Deep category now uses gpt-5.4 as its default model across all providers
(openai, github-copilot, venice, opencode), matching Hephaestus's GPT 5.4
upgrade. The requiresModel constraint is removed since gpt-5.4 is widely
available. Adds openai/gpt-5.3-codex -> openai/gpt-5.4 config migration
for existing user configs. Deep category prompt optimized for GPT 5.4's
stronger native capabilities (leaner, less verbose).
Align runtime defaults, tests, docs, and generated artifacts with the newer GPT-5.4 baseline. Keep think-mode and prompt-routing expectations consistent after the model version bump.
Fixes#1804, fixes#1962
The migration entry 'gpt-5.2-codex → gpt-5.3-codex' caused the plugin to silently overwrite user configs on every startup with a model that doesn't exist in the OpenAI API. Users explicitly setting gpt-5.2-codex (the correct current model) were forced to revert their config manually every session.
Move hashline_edit out of experimental so it is a stable top-level config with default-on runtime behavior and explicit disable support. Add migration and tests to preserve existing experimental.hashline_edit users without breaking configs.
Shorter hook name, disableable via disabled_hooks config, migration added
for backward compatibility. Also forces agent switch to Hephaestus on
Sisyphus + GPT detection. Docs updated with new hook name.
Migration changes were only applied to rawConfig if file write succeeded,
leaving the running process on stale config. Also stops logging backup
path when the backup copy itself failed.
Previously, migrateConfigFile() mutated rawConfig directly. If the file
write failed (e.g. read-only file, permissions), the in-memory config was
already changed to the migrated values, causing the plugin to use migrated
models even though the user's file was untouched. On the next run, the
migration would fire again since _migrations was never persisted.
Now all mutations happen on a structuredClone copy. The original rawConfig
is only updated after the file write succeeds. If the write fails,
rawConfig stays untouched and the function returns false.
YeonGyu-Kim