mixin conf file & env variables

[sysmat]

CLI Version

3.6.2

Operating System and Architecture

• macOS (arm64)
• macOS (x86_64)
• Linux (i686)
• Linux (x86_64)
• Linux (armv7)
• Linux (aarch64)
• Windows (i686)
• Windows (x86_64)

Operating System Version

all OS

Link to reproduction repository

No response

CLI Command

No response

Exact Reproduction Steps

Support mixing .sentryclirc configuration with environment variables

Summary

Recent versions of sentry-cli (tested with 3.6.2) no longer appear to support mixing configuration from .sentryclirc and environment variables as previous versions did.

Expected behavior

It should be possible to store non-sensitive configuration in .sentryclirc, for example:

• url
• org
• project

while providing sensitive values, such as SENTRY_AUTH_TOKEN, through environment variables.

The expected precedence would be:

1. Command-line arguments
2. Environment variables
3. .sentryclirc

This allows committing only non-sensitive configuration to source control while keeping authentication tokens in CI/CD secrets or local environment variables.

Current behavior

With sentry-cli 3.6.2, configuration does not appear to be merged correctly. If part of the configuration is provided via .sentryclirc and the rest via environment variables, the CLI fails instead of combining the two sources.

Why this is useful

Many projects use the following pattern:

• Commit .sentryclirc with shared project configuration.
• Provide SENTRY_AUTH_TOKEN through environment variables.
• Optionally override other settings in CI.

This avoids storing secrets in the repository while keeping the configuration simple and reusable.

Request

Please consider restoring support for merging configuration from .sentryclirc and environment variables, or clarify whether this behavior was intentionally changed. If it was an intentional change, documenting the recommended migration path would also be appreciated.

Expected Results

Support mixing .sentryclirc configuration with environment variables

Summary

Recent versions of sentry-cli (tested with 3.6.2) no longer appear to support mixing configuration from .sentryclirc and environment variables as previous versions did.

Expected behavior

It should be possible to store non-sensitive configuration in .sentryclirc, for example:

• url
• org
• project

while providing sensitive values, such as SENTRY_AUTH_TOKEN, through environment variables.

The expected precedence would be:

1. Command-line arguments
2. Environment variables
3. .sentryclirc

This allows committing only non-sensitive configuration to source control while keeping authentication tokens in CI/CD secrets or local environment variables.

Current behavior

With sentry-cli 3.6.2, configuration does not appear to be merged correctly. If part of the configuration is provided via .sentryclirc and the rest via environment variables, the CLI fails instead of combining the two sources.

Why this is useful

Many projects use the following pattern:

• Commit .sentryclirc with shared project configuration.
• Provide SENTRY_AUTH_TOKEN through environment variables.
• Optionally override other settings in CI.

This avoids storing secrets in the repository while keeping the configuration simple and reusable.

Request

Please consider restoring support for merging configuration from .sentryclirc and environment variables, or clarify whether this behavior was intentionally changed. If it was an intentional change, documenting the recommended migration path would also be appreciated.

Actual Results

cli fail

Logs

not valid token

[linear-code]

CLI-349

[kle-pra]

Same here. As 3.6.2 is only a patch update I think it should not be breaking.

[sysmat]

or add support for explicit env variable in .sentryclirc

[defaults]
url = YYYY
org = XXXX
project = my-project
SENTRY_AUTH_TOKEN=${MY_TOKEN}
[log]
level=trace

[szokeasaurusrex]

Hey @sysmat and @kle-pra 👋

There appears to be some confusion about the changes in 3.6.2: mixing configuration sources is, in general, still supported. The only items which can no longer be mixed between sources are the URL and auth token due to their sensitivity; other values, like the project and org, can still be combined.

The restriction on combining URLs and auth tokens is an intentional security fix. If the URL were taken from a configuration file while the authentication token came from another source, the token could potentially be sent to an unintended server and exfiltrated.

So, we are going to be keeping this behavior.

Next steps

You have a few options for adapting your codebase to this new behavior.

My recommendation is to use an organization auth token instead of a user auth token. You can identify such tokens by their sntrys_ prefix. These tokens embed the URL, and the embedded URL is always respected above any other configuration option, eliminating the need to separately configure a URL. As a bonus, an org auth token also embeds the org, so you don't need to configure that manually, either.

Alternatively, you can configure the URL alongside the auth token, treating it with the same sensitivity as the auth token.

In any case, you can keep the rest of your configurations as is.