These are drafts only. Nothing was filed or posted. Runtime observations use OpenCode 2.0.15 on macOS ARM64; v2.0.20 references are source inspection, not a tested binary.
The v2 CLI plugin context exposes named keymap layers, but no pre-dispatch catch-all or configured-leader matcher. A vimcode prototype with explicit public-layer bindings handled ASCII motions; unbound é and emoji leaked into normal/visual input and inserted after r instead of replacing. * is a literal binding; public plugins cannot register general key sequence patterns. shortcuts("leader") returned []; pending() identified the leader only after it fired.
A raw context.renderer.keyInput.prependListener("keypress", ...) works but depends on OpenTUI listener ordering. Request supported plugin-context equivalents of the internal Keymap.use().intercept("key", handler, { priority? }) with consumption and plugin-owned disposal, plus isLeader(event) or readable configured leader metadata. Acceptance tests should prove consumed printable keys never reach the composer, unconsumed keys do, a non-default space leader matches, and unloading removes the interception. This asks for a generic input extension, not built-in Vim behavior. Relevant source: public context, plugin API adapter, internal keymap.
With keybinds.leader: "space" in v2.0.15's cli.json, restart the TUI and create an idle synthetic session and string form using the public client. In a focused form textarea, typing hello leaves exact text hello while keymap.pending() shows { key: "space", token: "leader" }; subsequent letters can trigger shortcuts. This reproduces without vimcode. Expected: focused text-form input receives printable leader characters without losing intentional shortcuts for non-text controls. Ctrl+x accepted hello world. Vimcode's narrow renderer guard inserted the space in tested root and child forms, but does not fix the host. Source: v2 form, host keymap.
On v1.18.33 with isolated HOME/XDG, a ./tui-only plugin configured by the actual vimcode Git tag or a matching tarball is extracted but lacks :vim on first launch when XDG_CACHE_HOME is /tmp/... on macOS (/tmp resolves to /private/tmp). Restarting loads it. Change only the cache path spelling to /private/tmp/... with a fresh empty cache: both Git and tarball load on the first launch. The former lockfile contains a malformed ../../.../private/tmp/.../node_modules/vimcode key, whereas the canonical case uses node_modules/vimcode; standalone Arborist 9.1.6 showed empty versus populated installed edges. The v1 host bundles Arborist 9.4.0; its in-memory tree was not captured. This is not a general fresh-install failure. Request canonicalizing the installation root before Arborist reify and accepting an actually materialized node_modules/<name> TUI package when no edge is returned. A root-export stub is not safe: real v2 plugin add then selects server and writes opencode.json rather than CLI-only cli.json. Source: v1 installer, v2 installer.
Retain the ./tui-only package manifest. These reports can be reviewed with their isolated reproduction receipts before posting; see the POC strategy for compatibility limits.