Skip to content

V2 does not load managed config from %ProgramData%\opencode (V1 managed settings) #51107

Closed

Description

@ctmay4

Description

V1 documented a managed config directory (%ProgramData%\opencode on Windows, /etc/opencode on Linux, /Library/Application Support/opencode on macOS) loaded at the highest priority for admin-enforced settings. V2 does not appear to read it. The V2 migration guide lists only the global, project, and .opencode locations, and the policy precedence table doesn't include it.

Expected: Managed config is loaded with highest priority, as in V1. Per the migration guide, supported V1 behavior that stops working in V2 is a compatibility bug.

Impact: Organizations that use managed config to restrict providers lose that enforcement on upgrade to 2.x.

Plugins

No response

OpenCode version

2.0.16

Steps to reproduce

Place an opencode.json in C:\ProgramData\opencode defining a custom provider plus experimental.policies denying all other providers. It works in 1.18.32. In 2.0.16, the custom provider is missing and all built-in cloud providers appear. Copying the same file to ~/.config/opencode/opencode.json restores the expected behavior.

Screenshot and/or share link

No response

Operating System

Windows 11

Terminal

No response

Activity

  1. ctmay4 commented on Sep 24, 2026

    @ctmay4
    Author

    Following up with some source-code references from the v2.0.16 tag (commit 3a103fe) that may help narrow this down:

    Where the V2 loader lives, and why the managed dir is skipped

    V2's config discovery is in packages/core/src/config/discovery.ts, and the entry assembly is in packages/core/src/config.ts (Config.load). The full source list is:

    1. well-known (remote) configs
    2. global dir (~/.config/opencode)
    3. OPENCODE_CONFIG (explicit file)
    4. direct project opencode.json(c) files (outer → inner)
    5. .opencode/opencode.json(c) directories
    6. OPENCODE_CONFIG_CONTENT

    There is no source for the system-managed directory (%ProgramData%\opencode / /etc/opencode / /Library/Application Support/opencode). The only "managed" concept in V2 is packages/core/src/managed-policy.ts, which is about policies compiled by a connected OpenCode Console workspace — that doesn't help self-hosted/MDM-managed deployments that rely on the on-disk managed config.

    The V1 implementation being replaced

    For reference, the V1 equivalent is packages/opencode/src/config/managed.ts (1.x line), which reads the managed directory at highest file precedence and, on macOS, also reads .mobileconfig MDM plists via plutil. Both behaviors are missing in V2.

    Impact / workarounds

    This is blocking our fleet upgrade (many VPCs whose provider restrictions are enforced via managed config). We've confirmed two workarounds that restore the behavior on 2.0.16:

    • Deploying the same file to %USERPROFILE%\.config\opencode\opencode.json (per user), or
    • A directory junction from %USERPROFILE%\.config\opencode to %ProgramData%\opencode (single-user machines).

    Both lose the admin-only-writability of the managed location, so restoring the managed dir would be preferable.

    Suggested expectation for a fix

    Load <managed-dir>\opencode.json(c) in V2 with the same precedence as V1 — above all project/global file config, below Console-delivered policy statements — and keep the macOS MDM plist path, which would otherwise be a second silent regression for MDM-based fleets.

    Happy to test a build if there's a branch or snapshot where this is being addressed.

  2. rntdrts commented on Sep 25, 2026

    @rntdrts
    Contributor

    Opened #51337 against v2 with a fix: loads the system managed directory and the macOS ai.opencode.managed plist at the highest file precedence, with managed policy statements ranked below Console organization statements. V1-shaped managed files go through the normal migration, so enabled_providers becomes enforced policies. Happy to adjust if you'd prefer a different precedence model.

  3. added 19 commits that reference this issue on Sep 25, 2026
    41c5113
    57b1e7c
    25bc21f
    319f9ad
    f131e7e
    860b526
    5b2b686
    4a89c60
    8ce51cb
    d071894
    3053e2f
    a3bebe5
    fbd6243
    22c5f9e
    7e32c81
    f49c696
    08c1b30
    01e49b1
    9ad6c3b
  4. rekram1-node commented on Oct 13, 2026

    @rekram1-node
    Collaborator

    OpenCode V2 works a bit differently here — the system config folder is loaded first as a base default, and non-overridable rules are enforced through experimental.policies (which evaluate in reverse order, so system policies override user and project configs). If anything you need to enforce isn't covered by experimental.policies yet, let us know and we'll expand it.

    We will avoid breaking it even tho it's still listed as "experimental" it is already being used to power some features our console offering relies on, it just may get further extended.

    Edit:
    Copying for clarity:
    #51337 (comment)

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions