CLI: crash on startup when ~/.config/opencode directory mounted RO #56359

Activity

1. opencode-agent commented on Oct 17, 2026

   

   opencode-agentBot

   on Oct 17, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the clear report. I could reproduce this on v2.0.32. With an empty ~/.config/opencode bind-mounted read-only, opencode run hello fails with Server process exited with code 1 and the same EROFS ... service.json.tmp error you posted. On the latest dev (22e771f), the background server (opencode serve --service) still fails the same way when run directly.

   The cause appears to be that the background server always tries to save a generated password into service.json in the config directory if there isn't one yet.

   Workaround (confirmed on 2.0.32): put a service.json with a password in the host config directory before mounting it read-only, e.g.

   { "password": "<some long random string>" }

   With that file in place, opencode starts normally with the read-only mount.

   The script below reproduces the crash (it needs root for the read-only bind mount).

   Reproduction script (repro.sh)

   #!/usr/bin/env bash
   # Reproduce: opencode crashes on startup when ~/.config/opencode is read-only.
   # Needs root (for a read-only bind mount). Set OPENCODE_CMD to override the command.
   set -u
   CMD=${OPENCODE_CMD:-opencode}
   H=$(mktemp -d /tmp/opencode/home.XXXX)
   mkdir -p "$H/.config/opencode" "$H/project"
   mount --bind "$H/.config/opencode" "$H/.config/opencode"
   mount -o remount,bind,ro "$H/.config/opencode"
   touch "$H/.config/opencode/probe" 2>&1 | sed 's/^/check: /'
   cd "$H/project"
   # `opencode run` resolves the background service the same way the TUI does.
   HOME="$H" XDG_CONFIG_HOME= XDG_STATE_HOME= XDG_DATA_HOME= XDG_CACHE_HOME= \
     timeout 60 $CMD run "hello" 2>&1 | head -40
   echo "exit: ${PIPESTATUS[0]}"
   umount "$H/.config/opencode"

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

   added

   reproduced

   on Oct 17, 2026
3. harshitsharmaaaa commented on Oct 22, 2026

   

   harshitsharmaaaa

   on Oct 22, 2026

   More actions

   I've opened PR [#56539](#56539) to address this issue.

   The fix allows the local service to start when the configuration directory is read-only, while preserving the expected behavior when remote configuration requires password persistence. I've also added regression test coverage for this scenario.

   Feedback and review are welcome!