Problem
The consent bypass never fabricates its own detection evidence suite in packages/cli/src/commands/init.test.ts changes HOME to a temporary fake home but leaves XDG_CONFIG_HOME inherited. resolveOpenCodeConfigPath({ home: fakeHome }) prefers that inherited XDG path, so the OpenCode cases depend on a developer's real configuration and can write outside the test directory.
This is test isolation, not a proposed change to OpenCode's production XDG precedence. Two earlier suites in the same file already save, clear, and restore XDG_CONFIG_HOME.
Reproduction
- With
XDG_CONFIG_HOME unset for only the test process, this suite passes 13/13.
- With XDG pointed to a disposable directory, the suite passes 12/13 and writes
opencode/opencode.json under that directory. The final consent-write assertion fails because the preceding OpenCode case created detection evidence outside fakeHome.
- With XDG pointed to an existing OpenCode directory, three cases fail. The passing
opencode: the tick is still honoured once the tool is really there case also writes a config file under XDG in a controlled run.
During local PR #1806 validation, an empty OpenCode config file appeared in the real XDG directory. Its creation coincided with test execution, but the exact writer was not captured, so that file's attribution remains uncertain. The controlled runs establish the risk of writing to a real host path.
Suggested fix
Save and restore XDG_CONFIG_HOME in this suite. Point it at the suite's temporary root or clear it before each case, and assert all generated config paths remain inside that root. Keep the existing resolver-precedence tests in editors.test.ts to cover intentional XDG behavior separately. A regression run should set XDG to a pre-existing disposable OpenCode directory with a sentinel file and verify that the suite leaves the sentinel untouched.
Problem
The
consent bypass never fabricates its own detection evidencesuite inpackages/cli/src/commands/init.test.tschangesHOMEto a temporary fake home but leavesXDG_CONFIG_HOMEinherited.resolveOpenCodeConfigPath({ home: fakeHome })prefers that inherited XDG path, so the OpenCode cases depend on a developer's real configuration and can write outside the test directory.This is test isolation, not a proposed change to OpenCode's production XDG precedence. Two earlier suites in the same file already save, clear, and restore
XDG_CONFIG_HOME.Reproduction
XDG_CONFIG_HOMEunset for only the test process, this suite passes 13/13.opencode/opencode.jsonunder that directory. The final consent-write assertion fails because the preceding OpenCode case created detection evidence outsidefakeHome.opencode: the tick is still honoured once the tool is really therecase also writes a config file under XDG in a controlled run.During local PR #1806 validation, an empty OpenCode config file appeared in the real XDG directory. Its creation coincided with test execution, but the exact writer was not captured, so that file's attribution remains uncertain. The controlled runs establish the risk of writing to a real host path.
Suggested fix
Save and restore
XDG_CONFIG_HOMEin this suite. Point it at the suite's temporary root or clear it before each case, and assert all generated config paths remain inside that root. Keep the existing resolver-precedence tests ineditors.test.tsto cover intentional XDG behavior separately. A regression run should set XDG to a pre-existing disposable OpenCode directory with a sentinel file and verify that the suite leaves the sentinel untouched.