cli: discuss scoping for keychain-backed auth storage

[luojiyin1987]

Context

There is a TODO in packages/cli/src/user.ts:

export const USER_CONFIG_PATH = path.join(os.homedir(), '.e2b', 'config.json') // TODO: Keep in Keychain

The current CLI stores the following fields in ~/.e2b/config.json:

• email
• accessToken
• teamName
• teamId
• teamApiKey
• dockerProxySet

Problem

Moving this whole file directly into the system keychain looks desirable from a security perspective, but the implementation surface seems fairly large for an external contribution:

• touches the auth flow (auth login, auth configure, auth logout)
• affects config reads in api.ts
• needs migration for existing ~/.e2b/config.json
• requires a cross-platform secret storage backend (macOS Keychain / Windows Credential Manager / Linux Secret Service)
• likely introduces native/runtime dependency tradeoffs for the npm CLI

In addition, not all fields seem equally suitable for keychain storage. For example, dockerProxySet and team metadata look more like regular local config, while accessToken and teamApiKey are the actual secrets.

Proposal

Would you be open to splitting this work into smaller stages?

Stage 1

Refactor the CLI to separate:

• non-secret local metadata stored on disk
• secret values behind a dedicated secret-store interface

This stage could keep the current file-backed behavior and avoid changing user-visible behavior.

Stage 2

Introduce a real OS-backed secret store for the sensitive fields only:

• accessToken
• teamApiKey

This would also make it easier to discuss migration strategy and dependency choice separately.

Questions for maintainers

• Is the intended direction to move the entire user config into keychain storage, or only the sensitive fields?
• Would you accept an initial refactor PR that only introduces the storage boundary without yet adding a keychain backend?
• Do you already have a preferred cross-platform secret storage library / approach for the CLI?

If this direction sounds reasonable, I can follow up with a narrower implementation issue or PR proposal.

[linear]

ENG-3851