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.
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
model-resolver.test.ts and prometheus-agent-config-builder.test.ts use
spyOn(shared, 'log') but do not own the logger module. When other test
files in the same bun test process call mock.module('../shared/logger'),
the import cache is poisoned and the spyOn targets a stale binding.
Add a lightweight mock.module call at the top of each file so the
auto-detection in run-ci-tests.ts picks them up as isolated targets.
This ensures each file gets its own module instance and the spy
captures all calls correctly.
Fixes the flaky CI failure pattern where resolveModelWithFallback and
buildPrometheusAgentConfig tests pass locally (separate bun process)
but fail in the shared CI batch.
Agent names in the config.agent object (which becomes the /agent API
response) contained invisible Zero-Width Space (U+200B) characters
baked in by getAgentListDisplayName(). These ZWSP prefixes were used
for TUI sort ordering, but they leaked into the public API surface.
Impact: any prompt_async consumer that discovered agent names via the
/agent endpoint and passed them back to prompt_async without manual
ZWSP stripping got silent message drops — the agent name didn't match.
hy-pony's feishu-bridge integration went dark after upgrading to 3.16.0
with no error, no warning, and no indication that invisible Unicode
characters in agent names were the cause.
Fix: switch all four callsites from getAgentListDisplayName() (which
prepends \u200B×N) to getAgentDisplayName() (clean names):
- agent-key-remapper.ts: config keys → display names (was the primary
injection point)
- agent-priority-order.ts: CORE_AGENT_ORDER lookup (must agree with
the keys emitted by the remapper)
- command-config-handler.ts: command agent field normalization
- tool-config-handler.ts: agent config lookup (simplified fallback
chain since the primary lookup is now clean)
Sort ordering is preserved by:
1. JS object insertion order from reorderAgentsByPriority()
2. The injected `order` field (1-4) added by injectOrderField()
getAgentListDisplayName() is marked @deprecated with a link to #3238.
AGENT_LIST_SORT_PREFIXES and stripAgentListSortPrefix() are kept for
any internal callers that strip prefixes from legacy data.
Closes#3238
Test expected legacy parenthesized names but display names now use
dash format (Sisyphus - Ultraworker, not Sisyphus (Ultraworker)).
This was the flaky CI failure on dev.
Windows editors often save UTF-8 files with a BOM (Byte Order Mark: \uFEFF).
When this is present, jsonc-parser reports InvalidSymbol at offset 0 because
the BOM is not valid JSON/JSONC syntax.
This commit strips the BOM before parsing, fixing issues #3164 where Windows
users report their opencode.jsonc file fails to parse even though it appears
to start with a valid '{' character.
Fixes: #3164
Co-authored-by: Jobdori <agent@yeongyu.kim>
Display names with parentheses like 'Atlas (Plan Executor)' cause HTTP
header validation errors in x-opencode-agent-name. This was blocking
Atlas/Prometheus from working via /start-work and auto-retry.
Changes:
- Display names: parens -> dashes ('Atlas - Plan Executor')
- Hooks (start-work, no-hephaestus-non-gpt, no-sisyphus-gpt): use
config keys ('atlas', 'sisyphus', 'hephaestus') for agent API fields
- auto-retry: use config key instead of display name for promptAsync
- agent-override-protection: handle dash-suffix normalization
- Updated all test expectations to match new format
Closes#3138
Populate AGENT_LIST_SORT_PREFIXES for sisyphus/hephaestus/prometheus/atlas
so the TUI agent list renders in canonical order. Update dependent tests
to use getAgentListDisplayName() instead of hardcoded display strings.
🤖 Generated with [OhMyOpenCode](https://github.com/code-yeongyu/oh-my-opencode) assistance
Bug fixes:
1. OAuth token refresh (#3149): buildHttpRequestInit() now attempts silent refresh
via refresh_token before triggering full browser re-auth. Added refresh() method
to McpOAuthProvider. Includes test isolation fix for discovery mock.
2. Quota error STOP (#3126): Added STOP_MESSAGE_PATTERNS in model-error-classifier
that take precedence over RETRYABLE_MESSAGE_PATTERNS. Message-only quota errors
now non-retryable. Runtime-fallback: quota_exceeded with 'retrying in' signal
still triggers fallback (provider-managed auto-retry). Restored removed patterns.
3. Compaction loop (#3127): MAX_RECOVERY_ATTEMPTS=3 cap + additional suppression
guard from opencode session in degradation monitor.
Also: refactored extractAutoRetrySignal to auto-retry-signal.ts, new regression
tests for quota classifier and compaction degradation monitor.
Extract hephaestus into agentConfig before prometheus so the config
handler naturally assembles agents in the canonical order instead of
relying solely on reorderAgentsByPriority to fix the wrong intermediate
order. Also fix test data that had atlas/prometheus swapped and add
missing hephaestus to agent-config-integration test lists.
The todo-continuation-enforcer was passing raw agent names (which could be
display names like 'Sisyphus (Ultraworker)') to promptAsync. These names
contain spaces/parentheses that violate HTTP header specs, causing the
x-opencode-agent-name header validation to fail with 'unknown error' toast.
Added normalizeAgentForPromptKey() that converts display names to config keys
(e.g., 'Sisyphus (Ultraworker)' -> 'sisyphus') before API calls.
TDD: Added regression test that verifies config key is sent to promptAsync.
The \u200B (zero-width space) in AGENT_LIST_SORT_PREFIXES leaked into
the x-opencode-agent-name HTTP header, causing invalid header errors.
Agent ordering is handled by agent-priority-order.ts via numeric order
fields and insertion order — the ZWSP prefix was redundant.
Root cause: loadPluginConfig() unconditionally switched userConfigPath to the
canonical name after calling migrateLegacyConfigFile(), even when migration
failed (e.g. file lock on Windows, permission denied). This left the config
path pointing to a non-existent file, so the plugin config silently loaded
as empty defaults.
Additionally, several fallback/default paths were hardcoded to the legacy
'oh-my-opencode' basename instead of using CONFIG_BASENAME ('oh-my-openagent'),
causing CLI config commands (writeOmoConfig, detectCurrentConfig) to write to
the wrong filename.
Changes:
- plugin-config.ts: check migrateLegacyConfigFile() return value; only switch
to canonical path if migration succeeded OR the canonical file already exists
- opencode-config-dir.ts: use CONFIG_BASENAME for omoConfig path in
getOpenCodeConfigPaths()
- config-context.ts: getOmoConfigPath() now uses detectPluginConfigFile() to
find whichever name variant actually exists on disk
- plugin-config.ts: default fallback paths use CONFIG_BASENAME instead of
hardcoded legacy name
- Added test: loadPluginConfig still loads config when migration fails
(read-only directory simulation)
GitHub Copilot performs rolling model updates which sometimes return
'400 Bad Request' when a model is temporarily unavailable. This error
was not in the retryable message patterns, causing model fallback to
not trigger and users getting stuck.
Changes:
- Added 'bad request' to RETRYABLE_MESSAGE_PATTERNS in model-error-classifier.ts
- Added test cases for 'bad request' pattern matching
Fixes#3130
OpenCode supports plugin entries as [string, object] tuples for passing
options, but loadOpencodePlugins assumed all entries were strings.
When a tuple entry hit matchesKnownPlugin, it called .toLowerCase()
on an array, crashing the plugin on startup.
Extract the string name from tuple entries and skip non-string values.
Add regression test covering the tuple plugin format.
YeonGyu-Kim