[Bug]: Agent model configuration causes model to revert to default after sending message in web mode

[playeriv65]

Prerequisites

• I will write this issue in English (see our Language Policy)
• I have searched existing issues to avoid duplicates
• I am using the latest version of oh-my-opencode
• I have read the documentation or asked an AI coding agent with this project's GitHub URL loaded and couldn't find the answer

Bug Description

When oh-my-opencode is enabled and configured with agent-specific models, the model selection in OpenCode web mode does not persist after sending a message. After manually switching to a non-default model and sending a message, it automatically reverts to the oh-my-opencode configured default model.

Critical finding: When the oh-my-opencode plugin is disabled, this issue does not occur - the model selection persists correctly in web mode. This confirms the bug is caused by oh-my-opencode's interaction with OpenCode's web interface.

Steps to Reproduce

1. Configure oh-my-opencode with agent-specific models in ~/.config/opencode/oh-my-opencode.json (see Configuration section below)
2. Start OpenCode in web mode: opencode web
3. Open the web interface in browser
4. Observe that the model selector shows the oh-my-opencode configured model (e.g., Sisyphus shows "bailian-coding-plan/kimi-k2.5")
5. Manually switch to a different model in the web UI dropdown (e.g., to a different provider/model)
6. Send any message
7. Observe the bug: The model automatically switches back to the configured default (e.g., back to "bailian-coding-plan/kimi-k2.5")

Verification Steps (Confirming oh-my-opencode is the cause)

1. Disable oh-my-opencode plugin: rename or remove ~/.config/opencode/oh-my-opencode.json
2. Restart OpenCode web mode: opencode web
3. Switch to any model in the web UI
4. Send a message
5. Observe: The model selection persists correctly - confirming this is an oh-my-opencode bug

Expected Behavior

When oh-my-opencode is enabled, manual model selections in the web UI should persist after sending messages. The plugin should respect user-initiated model changes while still providing its default model configuration as the initial selection.

Actual Behavior

The model automatically reverts to the oh-my-opencode configured agent model immediately after sending a message. User's manual model selection is overridden.

Doctor Output

oMoMoMoMo Doctor 

⚠ 3 issues found:

1. Model override uses unavailable provider
   Provider(s) not found in OpenCode model cache: bailian-coding-plan
   Affects: model resolution

2. Comment checker unavailable
   Comment checker binary is not installed.
   Fix: Install @code-yeongyu/comment-checker
   Affects: comment-checker hook

3. No LSP servers detected
   LSP-dependent tools will be limited until at least one server is installed.
   Affects: lsp diagnostics, rename, references

Note: Issue #1 "Model override uses unavailable provider" may be related - the doctor reports bailian-coding-plan provider is not in OpenCode's model cache, but models still work. This could indicate the model configuration is being applied differently in web mode vs TUI.

Error Logs

No error logs are produced - the behavior is silent. The model switch happens without any visible error message.

Configuration

My oh-my-opencode.json configuration:

{
  "$schema": "https://raw.githubusercontent.com/code-yeongyu/oh-my-opencode/master/assets/oh-my-opencode.schema.json",
  "agents": {
    "hephaestus": {
      "model": "bailian-coding-plan/qwen3-coder-next"
    },
    "oracle": {
      "model": "bailian-coding-plan/qwen3-max-2026-01-23"
    },
    "librarian": {
      "model": "bailian-coding-plan/glm-4.7"
    },
    "explore": {
      "model": "bailian-coding-plan/MiniMax-M2.5"
    },
    "multimodal-looker": {
      "model": "bailian-coding-plan/kimi-k2.5"
    },
    "prometheus": {
      "model": "bailian-coding-plan/qwen3.5-plus"
    },
    "metis": {
      "model": "bailian-coding-plan/glm-5"
    },
    "momus": {
      "model": "bailian-coding-plan/glm-5"
    },
    "atlas": {
      "model": "bailian-coding-plan/glm-5"
    },
    "build": {
      "model": "bailian-coding-plan/qwen3.5-plus"
    },
    "plan": {
      "model": "bailian-coding-plan/qwen3.5-plus"
    },
    "sisyphus": {
      "model": "bailian-coding-plan/kimi-k2.5"
    },
    "sisyphus-junior": {
      "model": "bailian-coding-plan/glm-4.7"
    },
    "OpenCode-Builder": {
      "model": "bailian-coding-plan/qwen3-coder-plus"
    },
    "visual-engineer": {
      "model": "bailian-coding-plan/kimi-k2.5"
    }
  },
  "categories": {
    "visual-engineering": {
      "model": "bailian-coding-plan/kimi-k2.5"
    },
    "ultrabrain": {
      "model": "bailian-coding-plan/glm-5"
    },
    "deep": {
      "model": "bailian-coding-plan/qwen3.5-plus"
    },
    "artistry": {
      "model": "bailian-coding-plan/qwen3-max-2026-01-23"
    },
    "quick": {
      "model": "bailian-coding-plan/MiniMax-M2.5"
    },
    "unspecified-low": {
      "model": "bailian-coding-plan/glm-4.7"
    },
    "unspecified-high": {
      "model": "bailian-coding-plan/qwen3-coder-plus"
    },
    "writing": {
      "model": "bailian-coding-plan/glm-4.7"
    }
  },
  "options": {
    "background_tasks": true,
    "ultrawork_mode": "autonomous"
  }
}

Additional Context

• Issue is specific to oh-my-opencode: Confirmed by disabling the plugin, after which the issue disappears
• Only affects web mode: TUI (opencode terminal mode) works correctly
• The web UI model selector initially shows the correct oh-my-opencode configured model (e.g., Sisyphus shows "bailian-coding-plan/kimi-k2.5")
• Related upstream OpenCode issues suggest this may be a state management problem:
  • opencode #4281 - "Model switches back to the original selection after prompting"
  • opencode #8349 - "Model selection is 'lost' on continuation"
• Note from doctor output: The bailian-coding-plan provider shows as "unavailable" in model cache, which may indicate how oh-my-opencode applies model overrides differs between web and TUI modes

Operating System

Linux

OpenCode Version

1.2.20

Screen Recording

I will upload a screen recording demonstrating this bug shortly.

[playeriv65]

omo_issue.mp4