Summary
gws auth login prints an OAuth URL and waits for the user to open it manually. This is painful in environments where URLs get truncated (e.g. terminal emulators with limited column width, IDE integrated terminals, AI-assisted CLI tools) and when running in semi-automated workflows.
Problems
1. No auto-open browser option
The auth URL includes many scopes and parameters, making it extremely long. In many terminal environments the URL gets truncated or line-wrapped, making it unclickable. The user has to manually copy-paste the full URL.
Suggested fix: Add a --open / --browser flag (or make it the default) that calls open (macOS) / xdg-open (Linux) / start (Windows) to launch the URL in the default browser automatically.
2. Blocks indefinitely with no timeout
After printing the URL, gws auth login starts a local HTTP server and waits forever for the OAuth callback. If the user abandons the flow, closes the browser, or the callback fails silently, the process hangs with no way to recover except Ctrl+C.
Suggested fix: Add a --timeout <seconds> flag (e.g. default 120s) that exits gracefully with a clear error if the callback isn't received in time.
Environment
- gws version: 0.22.5
- OS: macOS 15, Apple Silicon (arm64)
Summary
gws auth loginprints an OAuth URL and waits for the user to open it manually. This is painful in environments where URLs get truncated (e.g. terminal emulators with limited column width, IDE integrated terminals, AI-assisted CLI tools) and when running in semi-automated workflows.Problems
1. No auto-open browser option
The auth URL includes many scopes and parameters, making it extremely long. In many terminal environments the URL gets truncated or line-wrapped, making it unclickable. The user has to manually copy-paste the full URL.
Suggested fix: Add a
--open/--browserflag (or make it the default) that callsopen(macOS) /xdg-open(Linux) /start(Windows) to launch the URL in the default browser automatically.2. Blocks indefinitely with no timeout
After printing the URL,
gws auth loginstarts a local HTTP server and waits forever for the OAuth callback. If the user abandons the flow, closes the browser, or the callback fails silently, the process hangs with no way to recover except Ctrl+C.Suggested fix: Add a
--timeout <seconds>flag (e.g. default 120s) that exits gracefully with a clear error if the callback isn't received in time.Environment