feat: enable OpenCode and Gemini launch agents#551
Conversation
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Greptile SummaryThis PR promotes OpenCode and Gemini (Antigravity) from catalog-only entries to fully launch-supported agents, wiring them into auto-selection priority, the settings dialog agent order, and the onboarding carousel agent list. Tests across config, registry, and native-agent are consistently updated to reflect the new set.
Note: A previous review comment flagged that Confidence Score: 5/5Safe to merge — changes are additive, well-tested, and consistent across all ordering arrays and test suites. All three places that maintain an agent order list (auto-selection priority, settings dialog, onboarding carousel) are updated in lock-step. Registry and native-agent tests are updated correctly, and the label rename for Gemini is reflected everywhere. The one gap — missing descriptions in resolveInstallInstructions — was already flagged by a previous reviewer and is cosmetic only. web-ui/src/components/task-start-agent-onboarding-carousel.tsx — resolveInstallInstructions still has no cases for opencode or gemini, leaving both with the generic fallback description during onboarding.
|
| Filename | Overview |
|---|---|
| src/core/agent-catalog.ts | Enables opencode and gemini in RUNTIME_LAUNCH_SUPPORTED_AGENT_IDS and updates gemini label; catalog entries already existed. |
| src/config/runtime-config.ts | Adds opencode (position 3) and gemini (last) to AUTO_SELECT_AGENT_PRIORITY; ordering is consistent with UI constants. |
| web-ui/src/components/task-start-agent-onboarding-carousel.tsx | Adds opencode and gemini to ONBOARDING_AGENT_IDS; resolveInstallInstructions still lacks cases for both, showing the generic fallback description in the onboarding UI. |
| web-ui/src/components/runtime-settings-dialog.tsx | Adds opencode and gemini to SETTINGS_AGENT_ORDER in the same position as the other ordering arrays; no issues. |
| test/runtime/config/runtime-config.test.ts | Updates priority-order and agent-normalization tests to reflect opencode/gemini being launch-supported; assertions are correct. |
| test/runtime/terminal/agent-registry.test.ts | Adds opencode and gemini assertions to buildRuntimeConfigResponse tests; agent order matches catalog order. |
| web-ui/src/runtime/native-agent.test.ts | Flips gemini isTaskAgentSetupSatisfied expectation from false to true and updates label; consistent with launch-support change. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Agent detected on PATH] --> B{In AUTO_SELECT_AGENT_PRIORITY?}
B -- No --> C[Skip]
B -- Yes --> D{In RUNTIME_LAUNCH_SUPPORTED_AGENT_IDS?}
D -- No --> E[Not shown in UI]
D -- Yes --> F[Shown in Settings & Onboarding]
F --> G{Priority rank}
G --> H["claude (1)"]
G --> I["codex (2)"]
G --> J["opencode (3) NEW"]
G --> K["droid (4)"]
G --> L["kiro (5)"]
G --> M["gemini (6) NEW"]
H & I & J & K & L & M --> N[Highest-ranked installed agent auto-selected]
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A[Agent detected on PATH] --> B{In AUTO_SELECT_AGENT_PRIORITY?}
B -- No --> C[Skip]
B -- Yes --> D{In RUNTIME_LAUNCH_SUPPORTED_AGENT_IDS?}
D -- No --> E[Not shown in UI]
D -- Yes --> F[Shown in Settings & Onboarding]
F --> G{Priority rank}
G --> H["claude (1)"]
G --> I["codex (2)"]
G --> J["opencode (3) NEW"]
G --> K["droid (4)"]
G --> L["kiro (5)"]
G --> M["gemini (6) NEW"]
H & I & J & K & L & M --> N[Highest-ranked installed agent auto-selected]
Reviews (2): Last reviewed commit: "feat(web-ui): show OpenCode and Gemini a..." | Re-trigger Greptile
|
Closing: this was intended as a personal fork branch for local testing, not an upstream contribution PR. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5d4b989cc9
ℹ️ 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".
| "cline", | ||
| "claude", | ||
| "codex", | ||
| "opencode", |
There was a problem hiding this comment.
With OpenCode now launch-supported, users can select it while Kanban's default agentAutonomousModeEnabled is true, but opencodeAdapter.prepare in src/terminal/agent-session-adapters.ts:1110 never translates that flag into OpenCode's documented --auto permission auto-approve option (see https://opencode.ai/docs/cli/). In default autonomous mode, OpenCode sessions will still stop on permission prompts, so auto-started tasks can hang until a user manually approves tools.
Useful? React with 👍 / 👎.
| "opencode", | ||
| "droid", | ||
| "kiro", | ||
| "gemini", |
There was a problem hiding this comment.
Adding gemini to the clean-install auto-selection list will persist it whenever the legacy Gemini binary is on PATH and no higher-priority agent is installed; Google's May 19, 2026 announcement says Gemini CLI stops serving free/Pro/Ultra consumer requests on June 18, 2026 while enterprise remains supported (https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/). Those users can end up with a default agent that appears configured but fails on task start instead of staying on the built-in path or being guided to the replacement CLI.
Useful? React with 👍 / 👎.
| { | ||
| id: "gemini", | ||
| label: "Gemini CLI", | ||
| label: "Antigravity / Gemini CLI", |
There was a problem hiding this comment.
Renaming this entry to Antigravity / Gemini CLI makes Settings/onboarding claim Antigravity support, but the catalog still only checks and launches the legacy gemini executable; Google's Antigravity codelab shows the replacement CLI installs and launches as agy (https://codelabs.developers.google.com/antigravity-cli-hands-on). Users who install Antigravity will therefore see this agent as not installed and cannot launch it from Kanban unless a separate agy binary/alias is supported.
Useful? React with 👍 / 👎.
| "cline", | ||
| "claude", | ||
| "codex", | ||
| "opencode", |
There was a problem hiding this comment.
When OPENCODE_CONFIG already points at a user's custom OpenCode config, enabling OpenCode launch makes Kanban task sessions overwrite that env var with the Kanban hook plugin config in opencodeAdapter.prepare, even though OpenCode documents OPENCODE_CONFIG as the custom config path loaded into its config merge chain (https://opencode.ai/docs/config/). In that setup, launches can lose provider/model/MCP settings from the user's custom file and fail or run against the wrong configuration.
Useful? React with 👍 / 👎.
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9993c0f8f8
ℹ️ 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".
| if (trimmed) { | ||
| if (input.startInPlanMode) { | ||
| const planningCommand = trimmed ? `/planning ${trimmed}` : "/planning"; | ||
| deferredStartupInput = toBracketedPasteSubmission(planningCommand); |
There was a problem hiding this comment.
When an Antigravity task is started with startInPlanMode, this branch removes the prompt from the CLI args and stores it in deferredStartupInput, but TerminalSessionManager only ever sends deferred startup input for Codex (entry.summary.agentId === "codex"). In that scenario the agy TUI opens without receiving /planning ..., so Kanban appears to start a plan-mode task but the agent does nothing until the user manually types the prompt.
Useful? React with 👍 / 👎.
| plugin: [pluginFileUrl], | ||
| }; | ||
| const baseConfig = await readOpenCodeConfigObject(baseConfigPath); | ||
| const config = mergeOpenCodePluginConfig(baseConfig, pluginFileUrl); |
There was a problem hiding this comment.
With hooks enabled, this copies the user's OpenCode config into Kanban's generated config under ~/.cline/kanban/hooks/opencode; OpenCode resolves {file:...} paths relative to the config file directory (https://opencode.ai/docs/config/#files), so a config like "apiKey":"{file:./openai-key}" that worked next to the user's config starts resolving under Kanban's hook directory. That breaks auth or instruction loading for configs that use relative file substitutions as soon as Kanban injects its plugin.
Useful? React with 👍 / 👎.
| } | ||
|
|
||
| function getAntigravityPluginDirectory(): string { | ||
| return join(homedir(), ".gemini", "antigravity-cli", "plugins", "kanban"); |
There was a problem hiding this comment.
This installs the Antigravity hook plugin in the user's global ~/.gemini/antigravity-cli/plugins/kanban directory, but antigravity-hook does not check for KANBAN_HOOK_TASK_ID before spawning a background kanban hooks notify. After one Kanban Antigravity launch, every normal agy session on the machine will run these hooks on each invocation/tool event and fork failing Kanban notification processes even though no Kanban task context exists.
Useful? React with 👍 / 👎.
| try { | ||
| return asObjectRecord(JSON.parse(rawConfig)); | ||
| } catch { | ||
| return asObjectRecord(JSON.parse(stripJsonComments(rawConfig))); |
There was a problem hiding this comment.
OpenCode config files commonly use JSONC syntax such as trailing commas, but this fallback only strips comments and then calls JSON.parse; when OPENCODE_CONFIG points to a valid .jsonc file with trailing commas, readOpenCodeConfigObject returns null and the generated hook config drops the user's provider/model/MCP settings. That leaves hook-enabled OpenCode launches without the custom config they normally rely on.
Useful? React with 👍 / 👎.
1 participant
Summary
Enable the existing OpenCode and Gemini CLI launch paths in my fork so I can test them directly.
Changes
Verification
Usage
This is mainly for testing OpenCode and Gemini CLI from my fork branch: happycastle114:feat/enable-opencode-gemini-agents.