anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-21 17:56:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: better navigation of output, alternative vim mode and non-blocking agent persmission requests #2701

New Issue
Open
opened 2026-02-16 17:36:53 -05:00 by yindo · 6 comments
yindo commented 2026-02-16 17:36:53 -05:00
Owner
Copy Link
Copy Source

Originally created by @ferdinandyb on GitHub (Nov 8, 2025).

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

So this became three things, because they all tie in together for a more thought-out interaction within the app.

Three issues:

  • hard to navigate output
  • vim-modes
  • agent accepting permission blocks input

Right now it's not that easy to keyboard navigate the output. A jump to bottom and top would be great. And I of course would like to be able to do it with gg and G.

This ties into somewhat with https://github.com/sst/opencode/issues/1764, because I'm not entire sure that the prompt area is the best place for a command mode. You actually already have a very irritating "command mode" where you can't continue typing your prompt if the agent is asking for permission. So you could have a normal mode where you can navigate output and issue single letter commands like open model, allow request etc, and an insert mode where you can do this with ctrl+something. I would very much like if accepting a request could be done without interrupting typing.

These issues can be solved separately, but it would be nice to have a clean, thoughtful interaction model.

Suggestion

Treat the input prompt field as the ex-mode of vim, where navigation is with more emacsy ctrl+something. Allow to bind everything in this :ex mode to ctrl+something type binding, even stuff like "accept" for permission requests (which should be non-blocking, since I assume they must block input now, because one of the input characters is "a"). The "normal" mode should be where you bind single letters to commands and navigate the chat history. Also things like y to copy entire block, and a visual mode for selecting what to copy exactly with the keyboard. And "insert" mode is really the editor mode, where you pull up vim. If you really want to go fancy, you could have a "full screen" version, and one where the editor is embedded into to prompt area only.

Originally created by @ferdinandyb on GitHub (Nov 8, 2025). ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request So this became three things, because they all tie in together for a more thought-out interaction within the app. Three issues: - hard to navigate output - vim-modes - agent accepting permission blocks input Right now it's not that easy to keyboard navigate the output. A jump to bottom and top would be great. And I of course would like to be able to do it with gg and G. This ties into somewhat with https://github.com/sst/opencode/issues/1764, because I'm not entire sure that the prompt area is the best place for a command mode. You actually _already_ have a _very_ irritating "command mode" where you can't continue typing your prompt if the agent is asking for permission. So you could have a normal mode where you can navigate output and issue single letter commands like open model, allow request etc, and an insert mode where you can do this with ctrl+something. I would very much like if accepting a request could be done without interrupting typing. These issues can be solved separately, but it would be nice to have a clean, thoughtful interaction model. # Suggestion Treat the input prompt field as the ex-mode of vim, where navigation is with more emacsy ctrl+something. Allow to bind everything in this :ex mode to ctrl+something type binding, even stuff like "accept" for permission requests (which should be non-blocking, since I assume they must block input now, because one of the input characters is "a"). The "normal" mode should be where you bind single letters to commands and navigate the chat history. Also things like `y` to copy entire block, and a visual mode for selecting what to copy exactly with the keyboard. And "insert" mode is really the editor mode, where you pull up vim. If you really want to go fancy, you could have a "full screen" version, and one where the editor is embedded into to prompt area only.
yindo added the opentuidiscussion labels 2026-02-16 17:36:53 -05:00
yindo commented 2026-02-16 17:36:53 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 8, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #1764: Feature request for vim keyboard shortcuts when writing the prompt (same vim mode request)
  • #2755: Copy Mode for OpenCode - comprehensive feature request for vim/tmux-like navigation and selection (covers navigation and copy functionality)
  • #3455: Make permissions dialog non-blocking and add modifier key shortcuts (same non-blocking permission request functionality)
  • #3370: Text selection and navigation inside input with keyboard (related navigation improvements)
  • #2232: Preserve Prompt on Ctrl+C (vim-related workflow improvements)

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Nov 8, 2025): This issue might be a duplicate of existing issues. Please check: - #1764: Feature request for vim keyboard shortcuts when writing the prompt (same vim mode request) - #2755: Copy Mode for OpenCode - comprehensive feature request for vim/tmux-like navigation and selection (covers navigation and copy functionality) - #3455: Make permissions dialog non-blocking and add modifier key shortcuts (same non-blocking permission request functionality) - #3370: Text selection and navigation inside input with keyboard (related navigation improvements) - #2232: Preserve Prompt on Ctrl+C (vim-related workflow improvements) Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:36:53 -05:00
Author
Owner
Copy Link
Copy Source

@itse4elhaam commented on GitHub (Dec 10, 2025):

This is indeed one of the pain points.

For now I just scroll up/down using the configured keybinds and then use the tmux copy keybinds to copy.

Would love this feature.

@itse4elhaam commented on GitHub (Dec 10, 2025): This is indeed one of the pain points. For now I just scroll up/down using the configured keybinds and then use the `tmux` copy keybinds to copy. Would love this feature.
yindo commented 2026-02-16 17:36:53 -05:00
Author
Owner
Copy Link
Copy Source

@julienberman commented on GitHub (Jan 7, 2026):

Ditto!

@julienberman commented on GitHub (Jan 7, 2026): Ditto!
yindo commented 2026-02-16 17:36:53 -05:00
Author
Owner
Copy Link
Copy Source

@arthur404dev commented on GitHub (Jan 14, 2026):

Can +1 on this, would be highly valued to have

@arthur404dev commented on GitHub (Jan 14, 2026): Can +1 on this, would be highly valued to have
yindo commented 2026-02-16 17:36:54 -05:00
Author
Owner
Copy Link
Copy Source

@KyrillGobber commented on GitHub (Jan 20, 2026):

Using opencode more and more, I stumble upon this issue as well. It happens extremely often that I just press k to scroll up in the output, but instead I'm typing in the input. Toggling between input and navigation would be the same as insert/normal mode in vim.
Toggle input with i, esc for staying in navigation. While navigating, besides the typical shortcuts like gg/G, j/k, ctrl+d/u, it would be awesome to have shortcuts to jump to the last user message (or do we already have this maybe?).

@KyrillGobber commented on GitHub (Jan 20, 2026): Using opencode more and more, I stumble upon this issue as well. It happens extremely often that I just press k to scroll up in the output, but instead I'm typing in the input. Toggling between input and navigation would be the same as insert/normal mode in vim. Toggle input with i, esc for staying in navigation. While navigating, besides the typical shortcuts like gg/G, j/k, ctrl+d/u, it would be awesome to have shortcuts to jump to the last user message (or do we already have this maybe?).
yindo commented 2026-02-16 17:36:54 -05:00
Author
Owner
Copy Link
Copy Source

@shelper commented on GitHub (Jan 22, 2026):

i think the first thing is to allow modify the cursor, right now the cursor is blob shape for input, but for vim that usually implies normal mode, and subconciousnessly, we press jk for scrolling

@shelper commented on GitHub (Jan 22, 2026): i think the first thing is to allow modify the cursor, right now the cursor is blob shape for input, but for vim that usually implies normal mode, and subconciousnessly, we press jk for scrolling
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion opentui
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2701
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?