Problem
The only way to persist auth is the interactive device-flow auth login. Token-based auth exists only as the ephemeral PUTIO_CLI_TOKEN env override, which:
- doesn't persist across sessions,
- can't be named/selected like a profile,
- pushes people toward pasting tokens into shells and chat sessions to make one-off calls work.
Proposal
Let a profile be created directly from an existing token:
putio auth login --profile web --token # prompts for the token on stdin, no echo
putio auth login --profile ci --token-stdin # reads from stdin for scripting
Behavior:
- validates the token against
/v2/oauth2/validate before persisting,
- stores it in the existing profile store alongside device-flow profiles,
auth status/auth profiles list mark the profile as token-sourced,
- never accepts the token as a bare argv value (
--token <value>), keeping it out of shell history and process lists.
PUTIO_CLI_TOKEN stays as the highest-precedence ephemeral override; this is the durable variant.
Problem
The only way to persist auth is the interactive device-flow
auth login. Token-based auth exists only as the ephemeralPUTIO_CLI_TOKENenv override, which:Proposal
Let a profile be created directly from an existing token:
Behavior:
/v2/oauth2/validatebefore persisting,auth status/auth profiles listmark the profile as token-sourced,--token <value>), keeping it out of shell history and process lists.PUTIO_CLI_TOKENstays as the highest-precedence ephemeral override; this is the durable variant.