cli: discuss scoping for keychain-backed auth storage

Open
#1,290 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
typescript
Domain
authentication, cli, security

Research direction

Read packages/cli/src/user.ts and trace auth login, auth configure, auth logout, and config reads in api.ts. Review the proposed separation of secret and local fields, migration needs, and cross-platform backend constraints. Done requires maintainer agreement on scope and a narrower implementation issue, since this issue currently asks design questions rather than specifying a change.

Written by the indexing model from the issue text.

Description

cli Improvement

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.

Dominant language
Python
Stars
13.9k
Forks
1k
Avg merge
1d 20h
Merged PRs (30d)
70

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from e2b-dev/E2B

All issues in e2b-dev/E2B

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.