Auth extension: set snowflake partner tag in setting

[sharon-wang]

Fixes #13731

Summary

Moves Snowflake partner-tag resolution into the authentication extension so Posit Assistant (and any future consumer) reads the User-Agent from authentication.snowflake.customHeaders instead of re-implementing the lookup. This gives us one source of truth for the value and lets authentication.snowflake.customHeaders (added in #13664) actually carry the partner tag by default.

On activation, the Snowflake auth provider seeds customHeaders["User-Agent"] with the resolved partner tag. Resolution precedence is environmentVariables.set.SF_PARTNER, then process.env.SF_PARTNER, then the default posit_positron. The schema default for customHeaders is { "User-Agent": "posit_positron" }, so "Reset Setting" gives you a valid tag instead of blanking the value.

Two guardrails:

• The extension remembers the last User-Agent it wrote (in globalState) and only overwrites values it wrote itself. If you've customised User-Agent in customHeaders, your value stays. The setting is the escape hatch for enterprise gateways and we don't clobber it.
• The write targets the most specific configuration scope where customHeaders is defined (workspace folder, then workspace, then global), since object settings don't merge across scopes.

Seeding runs on each activation, so changing SF_PARTNER and relaunching picks up the new tag automatically. No need to edit customHeaders by hand.

The duplicate resolution in positron-assistant's snowflakeProvider.ts can be removed in the Positron Assistant deprecation.

Validation Steps

@:posit-assistant

This is a config-seeding change with no direct UI. Validate manually:

1. Remove any existing authentication.snowflake.customHeaders setting and reload the window.
2. Open Settings, search for authentication.snowflake.customHeaders. Confirm it contains "User-Agent": "posit_positron".
3. Quit Positron, relaunch with SF_PARTNER=test-user-agent set in the environment, and confirm the value now reflects test-user-agent.
4. With the same setup, quit and relaunch without SF_PARTNER set. Confirm the value reverts to posit_positron (the extension overwrites its own prior seed).
5. Set User-Agent to a custom value in authentication.snowflake.customHeaders, reload, and confirm the value is preserved (not overwritten).
6. Unit tests:

npm run test-extension -- -l authentication --grep snowflakeCredentials

I was able to confirm this works by adding debug logging locally, and confirming that the user agent header was included with the snowflake request. There is not currently a way to see the headers directly from Posit Assistant.

1. Set SNOWFLAKE_ACCOUNT in authentication.snowflake.credentials
2. Login with Snowflake provider
3. Send chat message in Posit Assistant
4. See debug logs in devtools console, which include the user agent

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical @:posit-assistant

^{readme  valid tags}

[github-actions]

PETE's assessment 🧪

Verdict: Adequate -- The PR adds 183 lines of extension-host Mocha tests that cover every new exported function and every significant branch of the seeding logic.

What changed

• extensions/authentication/src/snowflakeCredentials.ts:+91 -- New getSnowflakePartnerTag() (3-level precedence: config env var → process env → default) and seedSnowflakePartnerTagHeader() (writes partner tag into customHeaders with guard logic to avoid clobbering user customizations)
• extensions/authentication/src/extension.ts:+8 -- Wires seedSnowflakePartnerTagHeader into registerSnowflakeProvider on activation
• extensions/authentication/package.json:+3/-1 -- Updates schema default for authentication.snowflake.customHeaders to carry { "User-Agent": "posit_positron" }

Tests in this PR

• extensions/authentication/src/test/snowflakeCredentials.test.ts (+183) -- Three new suites:
  • Partner Tag: all three precedence levels for getSnowflakePartnerTag() (setting > env > default)
  • Schema default: asserts package.json default equals { "User-Agent": "posit_positron" } via live extension manifest
  • Seed Partner Tag Header: 6 tests covering skip-when-already-set, skip-when-default-and-unset, skip-when-user-customized, overwrite-schema-default-when-SF_PARTNER-differs, overwrite-prior-seed-when-SF_PARTNER-changes, and most-specific-scope targeting with key merging

Existing coverage

New functions; no pre-existing tests to verify.

Suggested additions

None.

---

PETE (Positron Extreme Test Experiment) - LLM-based test-coverage advisor, in pilot. Triggers on PR open and on /recheck-tests comments. Wrong verdict? Add a /recheck-tests comment to this PR to re-run, or ping @jonvanausdeln. Please share feedback on how PETE performed here.

[sharon-wang]

• I noticed this while testing: Auth: review baseUrl and other auth settings for consistency across providers #13750

[timtmok]

Should the default value for authentication.snowflake.customHeaders be posit_positron? Otherwise, resetting the preference makes the value blank.

I also couldn't get the preference set by setting SF_PARTNER. The environment variable gets overridden with posit_positron. I thought the setting the environment variable would take precedence?

[sharon-wang]

/recheck-tests

[sharon-wang]

Should the default value for authentication.snowflake.customHeaders be posit_positron? Otherwise, resetting the preference makes the value blank.

I also couldn't get the preference set by setting SF_PARTNER. The environment variable gets overridden with posit_positron. I thought the setting the environment variable would take precedence?

ah thank you! I had opted out of setting the default value for authentication.snowflake.customHeaders to posit_positron, because the default value is different depending on if we're on desktop or Workbench, but revisiting this, I think it's better to just set the desktop default and adjust it afterwards, if we detect that we're on Workbench.

Also fixed up the env var precedence issue and added tests to cover these cases.

[timtmok]

I find that I can't set SF_PARTNER as an environment variable. It's always overridden and it looks like it's set by positron-environment here:

positron/extensions/positron-environment/package.json

Line 35 in 5e39a4f

"SF_PARTNER": "posit_positron",

Did this ever work to set the value by environment variable through the process? Or do we always have to set it with the preference?

[sharon-wang]

I moved #13731 forward to 2026.07. I feel like writing to customHeaders is maybe not a great direction to go in, because we have to deal with all this precedence complexity and I wonder if we may want to skew towards the old approach in Positron Assistant.

This precedence complexity doesn't seem like it should be the responsibility of the Auth extension. I'm not sure if we'd go with the approach in https://github.com/posit-dev/assistant/pull/1445 exactly, but maybe we lean towards that instead.

Putting this in draft in the meantime!