fix(core): load managed config directory and macOS managed preferences

[rntdrts]

Issue for this PR

Closes #51107

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

V1 loaded admin-managed config from the system directory (/Library/Application Support/opencode, /etc/opencode, %ProgramData%\opencode) and, on macOS, from MDM profiles in the ai.opencode.managed domain. The V2 loader never picked either up, so fleets that enforce providers or settings this way lose enforcement on upgrade.

This adds both sources back in Config.load, ranked above every other file. Managed text goes through the same normalize path as other config, so V1-shaped managed files keep working (e.g. enabled_providers becomes deny/allow policies). Wherever policies are evaluated (provider, MCP, skill and plugin checks), managed statements come after authored ones and before Console organization statements.

Managed paths are set through Config.Options (defaulting to the platform locations) rather than env vars, so a user can't point them elsewhere. Tests pass explicit paths, and the core test preload keeps a host's real MDM profile out of other suites.

Not included: watching managed files for changes (they apply on the next reload), and managed-dir plugin discovery.

How did you verify your code works?

• New tests in test/config/managed.test.ts and test/config/policy.test.ts: override of user/project/inline config, missing and malformed sources, plist ranking above the directory, V1-shaped managed config, and policy ordering against authored and Console statements.
• Full core suite: same failures as v2 without this change (all environment-related on my machine).
• Loaded my own Jamf-deployed V1 profile and managed opencode.json through the new loader: both documents load with no normalization diagnostics and provider policies are produced.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[rntdrts]

@rekram1-node not sure who to link here, but if someone can please take a look at this, I would appreciate it! 🙏

Thank you in advance!

[felipecrs]

I'd also appreciate if this PR was merged (or the bug was fixed).

[chetaldrich]

I'd also appreciate if this made it into main, as a user of v1.

[smdahlen]

+1 for this PR as well.

[jasontyping]

Strongly support this. This is also a security regression for sandboxed environments that rely on the managed config directory to restrict agents' ability to alter opencode configuration settings.

[bilogic]

deploying?

[bilogic]

Actually, opencode v2 does read /home/opencode.json, that's equivalent to /etc/opencode for me

[rntdrts]

Actually, opencode v2 does read /home/opencode.json, that's equivalent to /etc/opencode for me

Thanks for digging into this! Yes, v2 walks up parent directories, so an opencode.json in /home/ gets picked up when you're working under /home/. But that's project-config discovery, not the managed directory: user/global config still overrides it, and it only applies inside /home/**. Managed config (/etc/opencode, %ProgramData%\opencode, /Library/Application Support/opencode, plus macOS MDM profiles) sits above everything and applies regardless of cwd, that's what this PR restores.

[joe-workman]

Just wanted to say I built and tested this on macOS/ Windows and was able to push a .mobileconfig / %programData%/opencode config to update my allowed models in OpenCode, this is exactly what I need to manage this in my organization. Anything I can do to help?

[rntdrts]

Hi @joe-workman, thank you for taking the time to test it! 🙏 I've been sharing the PR in the Discord channel to catch a maintainer's eye for review. Hopefully, we can get a review soon!

[felipecrs]

I don't think there's a need to rebase unless there's a merge conflict.