project: NUL-byte project ID breaks fromDirectory and blocks TUI model selection #53991

Activity

1. github-actions

   assigned

   nexxeln

   on Oct 8, 2026
2. opencode-agent commented on Oct 8, 2026

   

   opencode-agentBot

   on Oct 8, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report and for finding the root cause. I reproduced this on 2.0.24. In a git repo whose .git/opencode holds 40 NUL bytes, opencode run fails with UnexpectedStatus: 500, and the log shows the same path ... without null bytes error for <data>/shell/\u0000…. The same repo without that file resolves normally. It still happens on the latest v2 commit (38c955e), run from source.

   The cached ID in .git/opencode is used as the project ID without checking that it is valid. When the file is corrupted, project resolution fails every time and never repairs itself. Related: #49997 reported the same null-byte shell path on v2.0.10. It was closed without a linked fix.

   Until this is fixed, the workaround you found (renaming .git so the directory isn't treated as a git repo) works. The script below reproduces the problem.

   Reproduction script (repro.sh)

   #!/usr/bin/env bash
   # Reproduces anomalyco/opencode#53991: a .git/opencode cache file full of NUL bytes
   # becomes the project ID, and project resolution then dies building <data>/shell/<id>.
   # Needs `opencode` (e.g. bun add -g @opencode/[email protected]) on PATH.
   set -u
   export HOME=$(mktemp -d)            # isolated data dir
   PROJ=$(mktemp -d)
   cd "$PROJ"
   git init -q
   head -c 40 /dev/zero > .git/opencode   # corrupted cached project ID (40 x 0x00)
   
   opencode --version
   timeout 60 opencode run --standalone "hi" 2>&1 | head -3      # -> Error: UnexpectedStatus: 500
   
   echo "--- log ---"
   grep -a -h "without null bytes" -r "$HOME/.local/share/opencode/log" | head -1 | cut -c1-300
   opencode service stop >/dev/null 2>&1 || true

   Run it: bash repro.sh
3. opencode-agent

   added

   reproduced

   on Oct 8, 2026
4. argszero commented on Oct 8, 2026

   

   argszero

   on Oct 8, 2026

   Contributor

   More actions

   I'd like to work on this.

   Confirming the root cause in the current v2 source, at the read rather than the write:

   • packages/core/src/project.ts reads the cached identity with cached() — fs.readFileString(path.join(dir, "opencode")), then value.trim(), then ID.make(value). trim() does not remove NUL bytes, so a 40-byte NUL file stays truthy and becomes the project ID. ProjectSchema.ID (packages/schema/src/project-id.ts) is a branded free-form string with no charset constraint, so nothing rejects it.
   • resolve() then prefers that value: const id = (yield* remote(repo)) ?? previous ?? (yield* rootCommit(repo)). With no remote, id === previous === <NUL bytes>, which is why adding a remote is the only thing that changes it and why migrateProjectId sees oldID === newID and returns before repairing anything.
   • The first path built from the ID is the shell output directory, path.join(global.data, DIRECTORY, location.project.id) (packages/core/src/shell.ts), which is the ERR_INVALID_ARG_VALUE ... without null bytes line in your log.

   Intended shape, kept small:

   1. In cached(), treat a cached value that cannot be used as a project ID — one containing control bytes — as absent, so resolution continues to the remote / root-commit / global sources and yields the same valid ID you got by renaming .git. This covers the Mercurial cache read too, since hgDiscover goes through the same helper.
   2. A test in packages/core/test/project.test.ts next to the existing returns previous cached id from common dir case: a repo whose .git/opencode holds NUL bytes resolves to the root commit and reports no previous.

   Deliberately out of scope, so the diff stays reviewable: no write-back of the cache (resolving intentionally does not write it today), no change to ProjectSchema.ID itself (legacy values such as the old-id in the current tests stay valid), and no repair pass over project rows that are already corrupted.

   Reviewers: tell me if you would rather have the guard at the point of use (the shell directory) or on the schema side instead, and I will follow that.
5. layermedya commented on Oct 8, 2026

   

   layermedya

   on Oct 8, 2026

   Author

   More actions

   Thanks for reproducing. Confirming from my side: after renaming .git away, the directory resolves to a valid ID and the TUI offers model selection again. Note the stale NUL-byte row stays in project and regenerates on every resolve until the cache file is fixed - happy to test the fix against my repro when ready.
6. argszero commented on Oct 8, 2026

   

   argszero

   on Oct 8, 2026

   Contributor

   More actions

   @layermedya the fix is up: #54030.

   It makes the cache advisory rather than authoritative — Project.cached() now treats a value carrying control characters as absent, so resolution falls through to the normal sources instead of adopting the corrupt value as the project id. That is the same path your renaming-.git workaround takes, so the directory should now resolve to a valid id without touching the cache file, and the stale row should stop being re-derived on each resolve.

   You offered to test against your repro — the branch is argszero:corrupt-project-id if you want to try it before it lands. Thanks for the clear report and for pinning down the read rather than the write side.