Driving a desktop VS Code window (target="nested:Visual Studio Code"), type_text reports typing the full string but only the first few characters arrive in the quick-input widget.
Reproduction (v0.39.0, Linux, nested sandbox):
run_actions target="nested:Visual Studio Code" actions=[
{"type":"key_press","key":"ctrl+shift+p","wait":"1s"},
{"type":"type_text","text":">View: Show Conversation","wait":"2s"},
{"type":"key_press","key":"Return"}
]
Result: the step reports typed 24 chars, but the palette input contains only >Vie — and Return then activates whatever the 4-character query happened to match, which is a different command. Same behaviour with ">Interact: New Session" (typed 22 chars -> >Int) and ">View: Join All Editor Groups" (typed 29 chars -> >View: Join All Editor, truncated at 22).
It is not the known >-prefix issue (that one is documented and I include the >): the prefix survives, the tail is lost. The truncation point varies (4, 4, 22 chars), which suggests the synthetic key events outrun the widget's own re-filtering/re-render — each keystroke re-queries and re-renders a long list, and keystrokes delivered during that render are dropped.
Cost: it silently activates the wrong command rather than failing, which reads like a wrong command name. It cost several round-trips this session, and once opened an unrelated command.
What would help:
- an inter-keystroke delay (configurable, or auto-applied for desktop targets), or
type_text verifying the resulting field value and retrying/reporting a mismatch instead of reporting typed N chars on the count it sent.
Workaround in use: type a short prefix, screenshot, then click the matching row by coordinates.
interact 0.39.0 · Python 3.13.1 · Linux-6.17.0-40-generic-x86_64-with-glibc2.39 · reported via report_issue
Driving a desktop VS Code window (
target="nested:Visual Studio Code"),type_textreports typing the full string but only the first few characters arrive in the quick-input widget.Reproduction (v0.39.0, Linux, nested sandbox):
Result: the step reports
typed 24 chars, but the palette input contains only>Vie— and Return then activates whatever the 4-character query happened to match, which is a different command. Same behaviour with">Interact: New Session"(typed 22 chars->>Int) and">View: Join All Editor Groups"(typed 29 chars->>View: Join All Editor, truncated at 22).It is not the known
>-prefix issue (that one is documented and I include the>): the prefix survives, the tail is lost. The truncation point varies (4, 4, 22 chars), which suggests the synthetic key events outrun the widget's own re-filtering/re-render — each keystroke re-queries and re-renders a long list, and keystrokes delivered during that render are dropped.Cost: it silently activates the wrong command rather than failing, which reads like a wrong command name. It cost several round-trips this session, and once opened an unrelated command.
What would help:
type_textverifying the resulting field value and retrying/reporting a mismatch instead of reportingtyped N charson the count it sent.Workaround in use: type a short prefix, screenshot, then click the matching row by coordinates.
interact 0.39.0 · Python 3.13.1 · Linux-6.17.0-40-generic-x86_64-with-glibc2.39 · reported via report_issue