fix(auth): make Login always prompt and harden org fetch

[John-David Dalton (jdalton)]

Closes SURF-414 (VSCode login not working for the customer "Copper").

A customer could not log in to the Socket extension at all. They ran "Socket Security: Login" from the command palette and nothing happened — no box to type a token into, no error message, no feedback of any kind. Running it again did the same nothing. With no way to enter a token, the extension was unusable for them.

Two things caused that dead end, and both are fixed here. The Login command now always opens the token prompt, even when the extension thinks it already has a session, so an explicit "Login" is never a silent no-op. And the call that checks a token against the Socket API can no longer throw, so a network problem surfaces as a visible "Invalid API key" instead of vanishing into a swallowed error.

Why the command did nothing — createIfNone only prompts when there is no session at all

The login command asked VSCode for a session with the option createIfNone: true. That option only shows the token prompt when no session exists yet.

The extension keeps a session in memory that it builds at startup from whatever token was saved on disk, and it never re-checks that token afterward. So if there is a leftover or expired token on disk, the extension still believes it has a session, createIfNone decides there is nothing to do, and the command returns having done nothing at all. The user is left with no way to enter a new token.

The change — always prompt, and make the token check total

Change	Effect
Login uses forceNewSession: true instead of createIfNone: true	The token prompt always runs, even when a session already exists, so an explicit "Login" always lets the user (re-)enter a token
The cancel-path rejection is swallowed	Dismissing the prompt is not reported as a command error
getOrganizations returns undefined on any failure instead of throwing	A rejected token, a non-200 response, an unreachable API, or a malformed body no longer throws out of the token-input validator or the file-watcher sync callback
The two organizations! non-null assertions go through firstOrganization	The call sites tolerate a failed fetch rather than throwing on it

getOrganizations previously threw straight out of the token-input validator and the file-watcher sync callback — for example when an unreachable API sits behind a corporate proxy.

What is covered by tests — the two testable pieces, extracted into vscode-free modules

Ran: tsc --noEmit, oxlint, oxfmt --check, and the test suite — all pass locally.

• getOrganizations and getAuthHeader moved to src/auth-api.ts; test/auth-api.test.mts (5 cases) uses nock (the shared test setup blocks real network) to assert getOrganizations returns the parsed body on a 200 and returns undefined on every failure mode — a non-200 (rejected token), an unreachable API, and a malformed non-JSON body — plus getAuthHeader's header formatting. This is the "total, never throws" behavior the fix depends on.
• firstOrganization in src/auth-org.ts; test/auth-org.test.mts (4 cases) covers the guard that stops a failed (undefined) fetch from throwing at the two call sites: undefined input, an empty organizations map, one organization, and picking the first of several.

auth.ts imports both modules for its own use and re-exports getAuthHeader / getOrganizations, so existing importers (the scores manager) are unchanged.

Not covered by a test: the Login command change itself (forceNewSession). It is thin wiring on the VSCode authentication API, and asserting it would require a behavioral VSCode test double, which the repo's no-mocking rule does not allow without approval. It is exercised by the build and the merge gate.

Could not verify — one open possibility needs customer confirmation

The recording confirms the "Login does nothing" symptom, and this PR fixes it. Both this ticket and SURF-416 are from the same customer (their lockfile is full of co.copper:* packages), which suggests an enterprise setup that is often behind a corporate proxy.

Node's https module does not honor VSCode's http.proxy setting, so if the customer is behind a proxy, token validation would still fail — but now it fails loudly ("Invalid API key") instead of silently. Proper proxy support would be a separate change and needs confirmation from the customer that a proxy is in play.

CI is red for an unrelated reason — a fleet-infrastructure failure that affects every PR in this repo

The red Check / Test jobs are a fleet-infrastructure failure in the shared bootstrap step (setup-and-install), which runs before any of this code. The same base tree is green on the main push run but red on pull_request runs; it affects every PR in the repo, not this change. Flagged to the team separately.

---

Note

Low Risk
Narrows to login command wiring and test stubs; behavior change is intentional UX fix with no auth or data-model changes beyond always showing the token flow.

Overview
Fixes SURF-414: when a stale or cached session already existed, Socket Security: Login did nothing because getSession used createIfNone: true, which only prompts when there is no session.

The login command now calls getSession with forceNewSession: true so the API token prompt always runs on an explicit login. A try/catch around that call treats a dismissed prompt as cancel, not a command failure.

Tests activate the extension through a stubbed vscode layer (authentication, commands, status bar) and assert the login handler only passes forceNewSession: true, and that dismissals resolve without throwing.

^{Reviewed by Cursor Bugbot for commit 9ee6c54. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{Bugbot Autofix is ON. A cloud agent has been kicked off to fix the reported issues.}

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 9ee6c54. Configure here.}

[cursor]

Login catch hides real failures

Medium Severity

The new Login catch swallows every getSession rejection, not only cancel. Failures from createSession such as no organization on a accepted token or a secrets.store error now end as a silent no-op, recreating the same “Login does nothing” experience this change aims to fix.

 

^{Reviewed by Cursor Bugbot for commit 9ee6c54. Configure here.}

[cursor]

Internal ticket ID in source

Low Severity

New comments embed the Linear-style id SURF-414 in shipped source and tests. Fleet public-surface hygiene forbids ticket refs in code and comments, so this leaks an internal tracker id into the public repo and extension bundle.

Additional Locations (1)

• test/auth.test.mts#L207-L210

 

^{Reviewed by Cursor Bugbot for commit 9ee6c54. Configure here.}