fix(doctor): guard tui.json tuple plugin entries in TUI plugin check (fixes #5786)

[MoerAI]

Summary

omo doctor falsely reported TUI plugin entry missing from tui.json whenever tui.json contained a valid "oh-my-openagent" entry alongside a tuple plugin entry such as ["./plugin.tsx", { ... }]. The tuple made a doctor predicate throw a TypeError, which the broad try/catch swallowed into an all-false registration state.

Root Cause

detectTuiPluginRegistration() and detectServerPluginRegistration() in tui-plugin-config.ts fed the raw parsed plugin array into predicates typed (entry: string) that call String.startsWith:

const plugins = parsed.plugin ?? []
return {
  registered: plugins.some(isTuiPluginEntry),
  hasNamedTuiEntry: plugins.some(isNamedTuiPluginEntry),  // <- throws on a tuple entry
  ...
}

OpenCode plugin config accepts tuple entries of the form [pathOrPackage, options]. When tui.json holds ["oh-my-openagent", ["./local.tsx", { ... }]], .some(isNamedTuiPluginEntry) iterates past the string entry, reaches the tuple, calls entry.startsWith(...) on an array, and throws TypeError: entry.startsWith is not a function. The surrounding catch treats that as an absent registration and returns registered: false, so doctor emits the misleading missing-entry warning.

Changes

File	Change
packages/omo-opencode/src/cli/doctor/checks/tui-plugin-config.ts	Filter the parsed plugin array to strings before evaluating predicates, in both detectTuiPluginRegistration() and detectServerPluginRegistration()
packages/omo-opencode/src/cli/doctor/checks/tui-plugin-config.test.ts	Add a regression case where tui.json pairs the package entry with a tuple plugin entry

The fix reuses the exact guard already used by pluginEntries() in add-tui-plugin-to-tui-config.ts: .filter((entry): entry is string => typeof entry === "string").

Reproduction (before fix)

104 |     //#then the tuple entry is ignored and our string entry still registers the plugin
error: expect(received).toBe(expected)
Expected: "pass"
Received: "warn"
(fail) tui-plugin-config check > passes when tui.json pairs our entry with a tuple third-party plugin entry

Verification (after fix)

(pass) tui-plugin-config check > passes when tui.json pairs our entry with a tuple third-party plugin entry
 14 pass
 0 fail

Test

• Regression test: packages/omo-opencode/src/cli/doctor/checks/tui-plugin-config.test.ts (1 case added)
• Related suite: bun test packages/omo-opencode/src/cli/doctor/ — 158 pass. The single spawn-with-timeout failure ("returns stdout and exit code") is a pre-existing Windows subprocess flake that reproduces identically on unmodified dev, unrelated to this change.
• Typecheck: tsgo -p packages/omo-opencode/tsconfig.json --noEmit — clean (exit 0)

Fixes #5786

---

Summary by cubic

Fixes a false “TUI plugin entry missing from tui.json” warning in omo doctor when tui.json includes tuple plugin entries. We now ignore tuple entries during checks so valid oh-my-openagent registrations pass.

• Bug Fixes
  • Filter plugin arrays to strings in detectTuiPluginRegistration() and detectServerPluginRegistration() to avoid calling string methods on tuples.
  • Added a regression test for a mixed config: ["oh-my-openagent", ["./local-tui-plugin.tsx", { ... }]].

^{Written for commit f56b615. Summary will update on new commits.}

[MoerAI]

I have read the CLA Document and I hereby sign the CLA

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f56b615c30

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Extract plugin names from tuple entries

When a user registers OMO itself with OpenCode's tuple form, e.g. ["oh-my-openagent", { ... }] in opencode.json, this filter drops the only server entry instead of normalizing it to the first tuple element. The rest of the repo already treats tuple entries as valid by taking plugin[0] in loadOpencodePlugins(), so checkTuiPluginConfig() will now report the server plugin missing even though OpenCode will load it; the same issue exists for the analogous tui.json filter below. Please normalize tuple entries to their first string element rather than filtering all non-strings out.

Useful? React with 👍 / 👎.

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

<sub>Auto-approved: Fix false positive in doctor check by filtering out non-string plugin entries. Small, safe change with regression test.

Re-trigger cubic</sub>