Weaver E10 Login Tool

Problem

Before calling Weaver E10 backend APIs, engineers usually need a valid session, a maintained ETEAMSID, and consistent handling of agent type and multi-environment differences. The Weaver E10 Login Tool is scoped to login and auth management, separating browser-based OAuth2.0 authorization, cookie writing, status checks, and user verification from business request code.

How It Works

• OAuth2.0 login: start a browser authorization flow with e10-login oidc --base-url ...; --agent_type can set values such as WorkBuddy, ClaudeCode, or Codex.
• Manual session entry: if localhost callbacks are blocked, copy ETEAMSID from browser DevTools and persist it with e10-login set --eteamsid ... --base-url ....
• Status and identity checks: e10-login status reports whether the cookie is expired; e10-login whoami calls backend teamsCheck to validate the current user, with --json for the raw payload.
• Multi-environment profiles: manage different baseUrl, passportUrl, and tenantKey values using profile list, profile use, and profile current.

Auth files are written to ~/.e10-cli/profiles/<profile>/auth, encrypted with AES-256-GCM and shared with e10-cli. cookies.raw stores the full cookie string and is preferred when sending requests because it can include fields such as langType and LOGIN_TYPE; if absent, the tool falls back to ETEAMSID=.... agentType is added to the cookie and also affects the User-Agent and isAgent=true marker.

Boundaries

This is not a general Weaver E10 business CLI. It does not wrap approvals, workflows, or business data queries directly; it focuses on login state, session files, and auth status. If the backend enforces extra rules around agent type, tenant isolation, or cookie expiry, each environment still needs explicit verification.