Skip to content

Support a configurable or platform-appropriate location for .mg\mg.graphoptions.json #3749

Open

Description

@btardif

Microsoft Graph PowerShell currently stores Graph SDK options at:

%USERPROFILE%\.mg\mg.graphoptions.json

The location is hard-coded in Microsoft.Graph.Authentication:

GraphDirectoryPath = Path.Combine(
    Environment.GetFolderPath(Environment.SpecialFolder.UserProfile),
    ".mg");

GraphOptionsFilePath is then constructed beneath that directory.

Source references in tag v2.36.1:

  • src/Authentication/Authentication.Core/Constants.cs
  • src/Authentication/Authentication/Constants.cs
  • src/Authentication/Authentication/Common/GraphSessionInitializer.cs
  • src/Authentication/Authentication/Cmdlets/SetMgGraphOption.cs

This creates another tool-specific dot-directory directly under the user profile, with no documented environment variable or configuration setting for relocating it.

Environment

OS: Windows
Microsoft.Graph.Authentication: 2.36.1
Current path: %USERPROFILE%\.mg\mg.graphoptions.json

The file contains SDK configuration options such as:

DisableWAMForMSGraph
DisableLoginByWAM

No authentication-token relocation is being requested in this issue; the immediate request concerns configuration files such as mg.graphoptions.json.

Expected behavior

Provide a supported way to relocate Microsoft Graph PowerShell configuration.

Possible approaches:

  1. Add an environment variable such as MSGRAPH_CONFIG_DIR.
  2. Follow platform conventions by default:
    • Windows: %APPDATA%\Microsoft\GraphPowerShell
    • Linux/macOS: $XDG_CONFIG_HOME/microsoft-graph, falling back to ~/.config/microsoft-graph
  3. Preserve the existing .mg location for backward compatibility and migrate or fall back to it when appropriate.

Motivation

A configurable location would:

  • Avoid adding application-specific directories to the profile root.
  • Support enterprise-managed and portable PowerShell environments.
  • Improve separation between configuration, cache, authentication state, and user data.
  • Allow consistent backup and profile-management policies.
  • Better align with platform conventions and the XDG Base Directory specification.

Existing related issue

#747 — Consider moving graph cache from .graph to .cache/graph to match XDG specification remains open.

That issue addresses Graph cache placement. This request is narrower and complementary: it covers the hard-coded .mg configuration directory and mg.graphoptions.json.

Acceptance criteria

  • A documented setting or environment variable controls the Graph PowerShell configuration directory.
  • Get-MgGraphOption and Set-MgGraphOption use the configured location.
  • Existing .mg configurations continue working through migration or backward-compatible fallback.
  • Windows, Linux, and macOS path behavior is documented and tested.
  • Configuration and cache locations can be controlled independently.

Activity

  1. earbona23 commented on Nov 5, 2026

    @earbona23

    This is still unassigned after 71 days, and I think it is worth separating from a feature request: the module already does both things, in two different places, so the inconsistency is internal.

    The token cache uses LocalApplicationData. src/Authentication/Authentication.Core/Utilities/TokenCacheUtilities.cs:34-36 builds DefaultCacheDirectory from Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), which is the platform-appropriate location this issue is asking for, and which honours XDG_DATA_HOME on Linux.

    The options do not. src/Authentication/Authentication.Core/Constants.cs builds its path from UserProfile plus a literal ".mg", so it lands in $HOME/.mg regardless of platform conventions.

    That means a container or a CI job that redirects the usual data directory moves the token cache and leaves the options behind, and the two can end up on different volumes.

    I have not opened a PR for this because the right shape is a maintainer call: whether to align Constants.cs with the SpecialFolder approach already used a few files away, or to introduce an environment variable alongside it. If either direction is wanted, I am happy to write it and test it on Linux, which is where the difference shows up.

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