Skip to content

Keep keystrokes working in the picker after login - #267

Merged
scotwells merged 1 commit into
mainfrom
fix/263-windows-picker-input
Aug 5, 2026
Merged

Keep keystrokes working in the picker after login#267
scotwells merged 1 commit into
mainfrom
fix/263-windows-picker-input

Conversation

@scotwells

@scotwells scotwells commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Fixes #263.

On Windows, arrow keys do nothing in the context picker that appears after datumctl login. The list renders, but the selection won't move. Passing --project/--organization or the env vars works, because those skip the picker.

Cause

The auth wait starts a background watcher so ^D can cancel it. The watcher polls stdin using read deadlines; when a stream doesn't support them it falls back to a plain blocking read that nothing can interrupt — not even the stop function called when login finishes. Windows console handles never support deadlines, so on Windows that read always parks on the terminal and stays there. The picker starts, and the two readers compete for one console: the stray one is still holding the terminal in line-input mode, so arrow keys get eaten by the console's own line editor before the picker ever sees them.

The watcher now probes deadline support before it starts, and declines to watch at all when it's unsupported. On those terminals the login wait is cancelled by ^C only — ^D never worked there anyway, since it isn't an end-of-input convention on a Windows console.

Unix is unaffected: a terminal is pollable there, so deadlines work and the watcher behaves exactly as before.

Verification

The bug reproduces off-Windows, because a regular file reports the same "deadlines unsupported" error a console handle does. Against the unfixed watcher, "hello\n" typed during the wait reaches the next reader as "ello\n" — the stolen keystroke, in miniature. Both new tests fail before the change and pass after, and they're platform-neutral so CI catches a reintroduction.

Still worth confirming on real hardware: the final step — a cooked-mode read swallowing arrow keys — is reasoned from the Windows console API, not observed, as none of us have a Windows machine. Everything upstream of it is verified from source.

@bmertens-datum, two things would help confirm this is the whole story:

  1. Does datumctl ctx with no arguments, in a fresh terminal with no login first, have working arrow keys? It should.
  2. During "Waiting for authentication callback...", does pressing Enter once make the picker work afterwards? A single keystroke satisfies the stuck read and frees the console.

On Windows, arrow keys did nothing in the context picker shown
after login: the background watcher that listens for ^D during
the auth wait could not be stopped there, so it stayed parked on
the terminal and swallowed the keys the picker was waiting for.
It now steps aside on terminals it cannot watch safely.

Fixes #263

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@bmertens-datum

Copy link
Copy Markdown
Contributor

@scotwells Tested on Win 11 Intel. Works as expected.

@bmertens-datum bmertens-datum left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

works for me. Thanks!

@scotwells
scotwells marked this pull request as ready for review August 5, 2026 15:21
@scotwells
scotwells merged commit 69b1874 into main Aug 5, 2026
4 checks passed
@scotwells
scotwells deleted the fix/263-windows-picker-input branch August 5, 2026 15:21
@scotwells

Copy link
Copy Markdown
Contributor Author

@bmertens-datum this is fixed in v0.18.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Project picker: arrow keys unresponsive on Windows PowerShell

3 participants