Update various modules to use centralized constants from plugin-identity:
- get-local-version/formatter: Use PUBLISHED_PACKAGE_NAME
- run/session-resolver: Use PUBLISHED_PACKAGE_NAME
- background-agent/task-poller: Use PUBLISHED_PACKAGE_NAME
- mcp-oauth/provider: Use PUBLISHED_PACKAGE_NAME
- auto-update-checker/constants: Use ACCEPTED_PACKAGE_NAMES
- comment-checker/downloader: Use PUBLISHED_PACKAGE_NAME
- legacy-plugin-toast/hook: Use PLUGIN_NAME
- shared/data-path: Use CACHE_DIR_NAME
- shared/external-plugin-detector: Use ACCEPTED_PACKAGE_NAMES
- shared/logger: Use LOG_FILENAME
- tools/ast-grep/downloader: Use PUBLISHED_PACKAGE_NAME
- tools/call-omo-agent/tools: Use PUBLISHED_PACKAGE_NAME
- tools/delegate-task/category-resolver: Use PUBLISHED_PACKAGE_NAME
- tools/grep/constants: Use PUBLISHED_PACKAGE_NAME
- tools/grep/downloader: Use PUBLISHED_PACKAGE_NAME
- tools/lsp/lsp-client-wrapper: Use PUBLISHED_PACKAGE_NAME
🤖 Generated with assistance of OhMyOpenCode
Update doctor checks to use centralized constants from plugin-identity:
- PACKAGE_NAME now references PUBLISHED_PACKAGE_NAME
- System check uses PLUGIN_NAME and LEGACY_PLUGIN_NAME for plugin
registration validation and legacy name detection
- Formatters updated for consistency
🤖 Generated with assistance of OhMyOpenCode
Update CLI installer to show oh-my-opencode (published name) instead
of oh-my-openagent (plugin name) in usage instructions.
🤖 Generated with assistance of OhMyOpenCode
Update systemLoadedVersion check to detect installs under both
oh-my-opencode and oh-my-openagent package names. Adds package
candidate selection logic for dual-published packages.
🤖 Generated with assistance of OhMyOpenCode
Update writeOmoConfig to detect and migrate legacy config files before
writing. Adds logic to handle oh-my-opencode.json -> oh-my-openagent.json
migration with proper path resolution and fallback handling.
🤖 Generated with assistance of OhMyOpenCode
Add CONFIG_BASENAME and LEGACY_CONFIG_BASENAME constants to support
migrating from oh-my-opencode.json to oh-my-openagent.json naming.
🤖 Generated with assistance of OhMyOpenCode
Extract hardcoded GPT apply_patch permission logic into a reusable module
to ensure consistent behavior across all agents. This prevents GPT models
from using the unreliable apply_patch tool while allowing other models.
- Add gpt-apply-patch-guard.ts with GPT_APPLY_PATCH_GUIDANCE and getGptApplyPatchPermission
- Update Hephaestus agent to use centralized permission logic
- Update Sisyphus-Junior agent to use centralized permission logic
- Update all GPT prompt builders to reference shared guidance constant
🤖 Generated with assistance of OhMyOpenCode
The /stop-continuation command was ineffective because the stop-
continuation-guard cleared its stopped state on the very next
chat.message event. Since any user message (including normal chat
after stopping) triggers chat.message, the continuation would
resume immediately.
Root cause: the chat.message handler called clear(sessionID) on
every user message, treating it as a 'user resumed work' signal.
But the user expects /stop-continuation to persist until they
explicitly start work again.
Changes:
- stop-continuation-guard chat.message: no longer clears stop state
- tool-execute-before: /start-work, /ralph-loop, /ulw-loop now
explicitly clear the stop state (so continuation resumes when
user intentionally restarts work)
- Updated and added tests: 12 pass (3 new), 125 related tests pass
Closes#3276
The resolveModelPipeline test was consistently failing on CI
(resolveModelPipeline > does not return unused explicit user config
metadata in override result) while passing locally. Root cause is the
same mock.module contamination pattern as #3243: when bun runs all test
files in a single process, mock.module calls from other files (e.g.
model-resolver.test.ts) leak into this file's module scope.
Add mock.module('./logger', ...) so run-ci-tests.ts auto-detects the
file and runs it in its own isolated bun process.
This unblocks the v3.16.1 publish workflow which hit this flake twice.
Remap the core agent keys, default agent, and command routing back to\nlist display names so OpenCode's name-based sorting keeps the\ncanonical Sisyphus -> Hephaestus -> Prometheus -> Atlas order.\n\nAlso teach tool config lookups to resolve the prefixed list keys and\nadd regression tests that exercise the real ordering and routing path.
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)
AGENT_LIST_SORT_PREFIXES prepended U+200B Zero Width Space characters
to the four core agent display names so they would sort ahead of user
agents in the Tab cycle. Two problems with that approach surfaced:
1. Some terminal emulators (Ghostty, certain Windows Terminal
builds) render ZWSP as a visible box or extra space, producing a
visible black gap in the status bar before "Sisyphus" and
misaligning the layout (#3259).
2. The prefixes leaked into the plugin API surface via config.agent
keys, breaking prompt_async consumers that received
ZWSP-contaminated agent names (#3238).
#3242 already removed every call site of getAgentListDisplayName() in
production code. That made the sort prefixes dead code: the constant
table was still defined but nothing read it. This PR finishes the
cleanup by:
- Deleting the AGENT_LIST_SORT_PREFIXES constant entirely
- Turning getAgentListDisplayName() into a thin alias over
getAgentDisplayName() for BC with external importers
- Keeping stripAgentListSortPrefix() as a legacy data migration for
users upgrading from v3.14.0-v3.16.0 whose config.agent keys may
still have ZWSP baked in from the old code path
- Documenting the history on stripAgentListSortPrefix() so future
maintainers understand why the stripper has to stay even after
the injector is gone
Sort ordering is preserved via JS object insertion order in
reorderAgentsByPriority() plus the `order` field it injects on the
four core agents. Both mechanisms are already in place and both
pre-date this PR; the ZWSP prefix was an older third layer that was
only meant to work around alphabetical sorting in legacy OpenCode
before the `order` field landed upstream.
Tests: 4445 pass, 0 fail. Added 3 new assertions to
agent-display-names.test.ts verifying that getAgentListDisplayName
returns plain names containing no zero-width characters. Updated
chat-message.test.ts to use a literal ZWSP string instead of the
helper so the defensive-strip path still has coverage.
Closes#3259
The auto-update-checker's version resolver hardcoded the canonical
oh-my-opencode package name in three read paths:
1. INSTALLED_PACKAGE_JSON pointed only at
cache/node_modules/oh-my-opencode/package.json
2. findPackageJsonUp() rejected any walked-up package.json whose name
did not equal PACKAGE_NAME
3. getLocalDevPath() only matched file:// plugin entries whose path
contained the canonical name
The publish pipeline ships the same code under two npm package names
(oh-my-opencode canonical, oh-my-openagent alias). Users who add
"oh-my-openagent" to their opencode config end up with
node_modules/oh-my-openagent/package.json, so every read path above
silently missed the installed version and the startup toast fell back
to "unknown".
Introduce ACCEPTED_PACKAGE_NAMES + INSTALLED_PACKAGE_JSON_CANDIDATES in
constants.ts and teach the three readers to accept both names. Writes
are untouched (sync-package-json, pinned-version-updater, cache
invalidation) because the auto-update-checker still owns its own cache
workspace and writes to the canonical name there.
Tests: 54 auto-update-checker tests pass (4 new), full 4444-test suite
passes, tsc clean. New tests cover both install paths, the walk-up
resolver, and the priority order when both candidates exist.
Closes#3257
YeonGyu-Kim