fix(opencode): read an empty OPENCODE_CONFIG_DIR as unset, not as a relative path

[worktrunk-bot]

wt config plugins opencode install writes the plugin to a relative plugins/worktrunk.ts — i.e. into whatever directory wt was run from, typically the user's repo — when OPENCODE_CONFIG_DIR is exported with an empty value. is_plugin_installed() and plugin_file_exists() then read that same relative path back, so the install reports success while OpenCode never sees the plugin.

The cause is a one-branch gap in opencode_plugins_dir: the XDG_CONFIG_HOME arm filtered empty values, the OPENCODE_CONFIG_DIR arm above it did not, so PathBuf::from("") passed through as a valid config directory. Every other agent-config override in the tree already reads an empty value as unset — CLAUDE_CONFIG_DIR in commands::config::show, PI_CODING_AGENT_DIR and PI_CONFIG_DIR in commands::config::pi — so this arm was the odd one out rather than a deliberate choice.

The documented precedence is unchanged: $OPENCODE_CONFIG_DIR > $XDG_CONFIG_HOME/opencode > ~/.config/opencode. Only the reading of an empty value moves, from "a directory named """ to "unset".

The regression test runs the real install from a scratch directory with OPENCODE_CONFIG_DIR="", then asserts the plugin landed under $XDG_CONFIG_HOME/opencode/plugins/ and that nothing was written relative to the invocation directory. It fails against the previous code on the first assertion.

[worktrunk-bot]

Reviewed 24e8878, which has since been force-pushed away. Both findings below are resolved at the current head — see the note at the end.

Two checks are red on this head, and both are the PR's own.

affected tests (windows, advisory) is a real failure, not an advisory flake. empty_override_falls_through_to_xdg panics on must not resolve against the CWD: on Windows PathBuf::from("/xdg").join("opencode") is \xdg\opencode, which has a root but no drive prefix, so Path::is_absolute returns false. The assertion is testing the fixture rather than the resolver — the assert_eq! on the line above already pins the whole returned value, which is what proves the empty override didn't fall through to a relative path. Required test (windows) is still pending on this head and will fail the same way.

codecov/patch is at 93.75%, and the single missed line is closable. The cobertura report for this head has exactly one uncovered line among the 16 counted non-test additions: the bare )?; closing the multi-line call in opencode_plugins_dir, whose only region is the error propagation from home_dir(). Binding the two env reads first puts the ? on a line that also carries the executed call, so the line reports hit — no test contortion, and the call reads more plainly besides. That takes the patch to 16/16.

---

Superseded. The branch was force-pushed to 9e42190 while this review was being written. That commit inlines the empty-value filter back into opencode_plugins_dir and drops the extracted opencode_config_dir helper along with its three unit tests, replacing them with an integration test that runs the real install from a scratch directory and asserts nothing lands under the invocation path. Both lines above are gone as a result — the Windows is_absolute assertion and the lone )?; no longer exist — so I am not pushing the fixes I said I would. The new head carries neither finding and gets its own review.

[worktrunk-bot]

The fix and its guard check out: reverting the filter(|s| !s.is_empty()) locally makes the new test fail on the XDG assertion, and restoring it makes it pass. Three things before this merges.

The same empty-value gap is still live where wt writes the user's zsh rc file. line_based_config_paths in src/shell/paths.rs resolves zsh's config as std::env::var("ZDOTDIR").map(PathBuf::from).unwrap_or_else(|_| home.to_path_buf()), so an exported-but-empty ZDOTDIR yields the relative .zshrc — the same shape as the bug fixed here, on a file wt config shell install appends to and uninstall rewrites whole. The consequences are worse than a stray plugin file: ~/.zshrc drops out of the candidate list entirely, so install skips zsh for want of a config location; and where the cwd does hold a .zshrc — a dotfiles repo being the obvious case — the integration line lands in that file instead. scan_for_detection_details in src/shell/detection.rs reads ZDOTDIR the same way, which is what wt config show's shell section reports from, and legacy_nushell_autoload_dirs in src/shell/paths.rs does the same with XDG_CONFIG_HOME (PathBuf::from(xdg_config).join("nushell")), handing uninstall's stranded-file search a relative path. nushell_data_dir_fallback, immediately above it in the same file, already guards its XDG_DATA_HOME read with path.is_absolute(), so the guard is that file's own convention rather than a new idea. Those sites write and rewrite user rc files, so they want their own change rather than being folded in here — but they shouldn't be left standing either.

code-coverage is red on 9e42190 for a reason unrelated to the diff, so codecov/patch never posts for this head. All 4859 tests passed and the job then died merging profiles: invalid instrumentation profile data (file header is corrupt), then error: no profile can be merged. That is a corrupt .profraw — transient infrastructure, not a coverage gap. The changelog push below re-runs it, and the patch number stays unverified until that lands.

No changelog entry. Every comparable fix(…) on main carries one under ## Unreleased → ### Fixed — #4067, #4073, #4061, #4058 — and the symptom here (install reports success while writing into whatever directory wt ran from, and OpenCode never sees the plugin) is what that section is for. Pushing one.