Fixes the following accessing issue:
```
Error accessing credential on keyring: PlatformFailure(Error { code: -25308, message: "User interaction is not allowed." })
```
On Darwin, `services.podman` mounts `~/.config/containers` into the Fedora CoreOS VM, but this did not work correctly for two reasons:
* `xdg.configFile` creates symlinks into `/nix/store`, which are broken inside the guest.
* The mount target `~/\.config/containers` is not canonical on Fedora CoreOS, so Podman rejects it.
To fix this, we now:
* materialize the generated Podman config files as real files with `runCommand`
* sync them into `~/.config/containers` during activation, between `linkGeneration` and `podmanMachines`
* use the canonical guest path `/var/home/<user>/.config/containers`
Because adding the config directory to the volume mounts overrides the defaults, we also restore the default Podman volumes as the defaults for the `machines.<machine>.volumes` attribute while still allowing full overrides.
This change does not affect Linux: `xdg.configFile` still produces store symlinks there.
Closes#9327.
Specifically, the machine initialization command `podman machine init`
requires `ssh-keygen` to generate keys, but `openssh` may not be
available in the system `PATH` by default. This change ensures
`openssh` is available before attempting to create podman machines.
Resolves#9325
Add `enableMcpIntegration` option to merge MCP servers from
`programs.mcp.servers` into Claude Code configuration. Claude Code
servers take precedence over general MCP servers when both define
the same server name.
- restructure module from `podman-linux` to platform-agnostic `podman`
- move linux-specific implementation to `modules/services/podman/linux/`
- add darwin module with declarative machine management
- implement launchd-based watchdog for auto-starting machines
- maintains backward compatibility with existing linux functionality
Adds support for custom tools - user-defined functions that the LLM can
call during conversations. Custom tools work alongside opencode's built-in
tools and are configured through the new `tools` option.
The configuration follows the same pattern as other opencode settings like
`agents` and `commands`, supporting:
- Inline TypeScript content
- Individual file paths
- Bulk directory imports
The `commands`, `agents`, and `themes` options now accept either an
attribute set (existing behavior) or a path to a directory containing
multiple files. When a directory path is provided, it is symlinked to
the appropriate `$XDG_CONFIG_HOME/opencode/` subdirectory.
This change aligns with the existing `skills` option implementation and
provides a more convenient way to manage multiple configuration files
without needing to define each one individually in Nix.
Replace the use of `~` in the documentation for the command and agent
settings with the `XDG_CONFIG_DIR` environment variable to avoid
ambiguity about the config directory. Also switch to the
`{file}` path macro so paths render correctly in the docs and tooling.
- Configuration file is now placed in XDG_CONFIG_HOME/codex/config.toml by default for versions >=0.2.0 when preferXdgDirectories is enabled.
- Falls back to ~/.codex/config.yaml for versions <0.2.0 and to ~/.codex/config.toml when preferXdgDirectories is disabled
- Sets CODEX_HOME environment variable to $XDG_CONFIG_HOME/codex when using XDG directories.
- Updated tests to verify XDG directory behavior and environment variable presence.
- Automatically include "$schema": "https://opencode.ai/config.json" in the generated
opencode config.json file
- Update documentation to mention the added schema property
- Add corresponding "$schema" entry in test config.json file for validation purposes
Closes#7506
- Introduce `rules` option to provide global custom instructions for opencode
- Write `rules` content to `~/.config/opencode/AGENTS.md` if non-empty
- Update tests to cover presence and absence of `AGENTS.md` file with rules content
On macOS, configuration files are stored in the platform-standard
directory `~/Library/Application Support/` by default. However, if the
user enables the XDG Base Directory specification by setting
`xdg.enable = true`, iamb should respect the `XDG_CONFIG_HOME`
environment variable (along with other related XDG variables).
Currently, this behavior is not implemented in iamb, a PR has been
opened to fix that -> https://github.com/ulyssa/iamb/pull/478.
