Description
Opencode creates state files (log, session data and alike) in XDG_DATA_HOME which does not follow the specification.
From the specification:
The $XDG_STATE_HOME contains state data that should persist between (application) restarts, but that is not important or portable enough to the user that it should be stored in $XDG_DATA_HOME. It may contain:
-
actions history (logs, history, recently used files, …)
-
current state of the application that can be reused on a restart (view, layout, open files, undo history, …)
Logs, history and session data should be stored in XDG_STATE_HOME. XDG_DATA_HOME is more akin to the user specific equivalent of /usr/share/ not a place to store runtime data.
Three concrete problems with the current implementation:
- Running opencode in a container along other tools does not allow for a singe state related mapping opencode needs an exception to the general rule.
- Deleting
$XDG_STATE_HOME should put all applications in a fresh "unused" state. Which does not happen in opencode's case.
- It makes it totally unclear which files a user would need to backup, migrate or sync to a new machine.
Plugins
No response
OpenCode version
1.2.27
Steps to reproduce
- Start opencode
- Execute some prompts
Screenshot and/or share link
No response
Operating System
Linux (alpine)
Terminal
any
Description
Opencode creates state files (log, session data and alike) in
XDG_DATA_HOMEwhich does not follow the specification.From the specification:
Logs, history and session data should be stored in
XDG_STATE_HOME.XDG_DATA_HOMEis more akin to the user specific equivalent of/usr/share/not a place to store runtime data.Three concrete problems with the current implementation:
$XDG_STATE_HOMEshould put all applications in a fresh "unused" state. Which does not happen in opencode's case.Plugins
No response
OpenCode version
1.2.27
Steps to reproduce
Screenshot and/or share link
No response
Operating System
Linux (alpine)
Terminal
any