Skip to content

config: edits to symlinked global config target do not trigger hot reload #53920

Description

@ykai55

Description

In V2, editing the target of a symlinked global opencode.json leaves the running shared service using the old model limits. Touching the symlink itself with touch -h makes the new values take effect without restarting or explicitly reloading.

Expected: edits to the configuration's resolved target should trigger automatic reload.

Plugins

Custom plugins: chat-notify, current-time, rename-self, provider-loader. Not yet reproduced with custom plugins disabled.

OpenCode version

2.0.24 (latest channel)

Steps to reproduce

  1. Use a symlinked global config: ~/.config/opencode/opencode.json -> ~/dotfiles/opencode/opencode.json. The parent config directory is not itself a symlink.
  2. Start the shared service, then edit the target file. In the observed case, add provider.openai.models["gpt-6.1-sol"].limit with {"context":1050000,"input":922000,"output":128000} (the existing config uses the compatible singular provider key).
  3. Query the effective model:
    opencode api get /api/model |
      jq '.data[] | select(.providerID == "openai" and .id == "gpt-6.1-sol") | {id, limit}'
    It continues returning {"context":400000,"input":272000,"output":128000}.
  4. Without editing the file again or restarting the service, run:
    touch -h ~/.config/opencode/opencode.json
  5. Repeat the query. It now returns {"context":1050000,"input":922000,"output":128000}.

The symlink-touch comparison was performed once. A similar stale-config symptom was observed with another model; opencode api post /api/location/reload applied that change successfully. Logs show a directory watcher subscription for ~/.config/opencode. A symlink-target detection issue is suspected, but the implementation-level cause has not been confirmed.

Related: #39738 concerns initial config loading in V1, rather than this V2 hot-reload behavior.

Screenshot and/or share link

Not applicable; effective API values and commands are included above.

Operating System

macOS, Darwin 25.6.0, arm64

Terminal

tmux (TERM=xterm-256color, COLORTERM=truecolor)

Activity

  1. opencode-agent commented on Oct 8, 2026

    @opencode-agent
    Contributor

    Thanks for the detailed report, I was able to reproduce this on 2.0.24 (on Linux). It still happens on the latest v2 branch (0621ea9).

    Setup: ~/.config/opencode is a real directory, and ~/.config/opencode/opencode.json is a symlink to ~/dotfiles/opencode.json. With the shared service running, I overwrote the target three times, each time with a different provider.opencode.models["exo-free"].limit.context (1111, 2222, 3333), and checked opencode api get /api/model after each:

    • 1111: picked up
    • 2222 and 3333: still 1111 (stale)
    • after touch -h ~/.config/opencode/opencode.json: 3333

    In my clean runs, the first edit after the service started was picked up and later edits were missed. In one run where the target already had content, even the first edit was missed until touch -h, which matches what you saw. Either way, edits to the symlink target are not reliably detected until the symlink itself is touched.

    Until this is fixed, touch -h on the symlink or opencode api post /api/location/reload will apply the change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions