Skip to content

Editing WT actions can silently break them #19464

Open

Description

Windows Terminal version

1.25.251014001-llm

Windows build number

10.0.19045.6332

Other Software

No response

Steps to reproduce

  1. Open WT

  2. Settings - Actions

  3. Remove all the predefined actions (It can take a while, yes. Perhaps it would make sense to have an Action for that as well? :) )

  4. Press Add new

  5. Make sure your keyboard layout is US English.

  6. Type / (should be close to right Shift)

  7. Press Accept.

  8. Press Save.

  9. You should see it now:
    Image

  10. Add a keyboard layout with a different placement of /, e.g. Ukrainian.

  11. Switch to that layout.

  12. Suddenly wild "Open default settings file (JSON)" and "Open settings file (JSON)" actions appear!
    Image
    Why? I didn't ask for them. I explicitly removed everything. Why my choices are not respected?

  13. Notice that / is now suddenly called shift+\.
    However, it makes sense if you look at the layout again - it is in the upper case of the \ key close to Enter, so it is shift+\ indeed:
    Image
    Which is kinda cool: WT is smart enough and user-friendly enough to show me what exactly we need to type now in this particular layout to get what we want. Nice. What could possibly go wrong, right?

  14. But there are still those two sudden actions we haven't asked for. Probably it's some bug in WT, but it's not a big deal, we can just remove them manually.

  15. Press Edit - Delete - Yes on each.

  16. Press Save.
    Image

  17. Switch back to US English layout.

Expected Behavior

The action I've added should change back to /, same as it did before I removed those two extra actions.
It should trigger when I press / in US English (the key close to right Shift).

Actual Behavior

The action I've added does not change back to / when I switch to US English. It stays shift+\.
Pressing / in US English doesn't trigger it anymore.

If I open the json, it becomes obvious what happened:

    "keybindings": 
    [
        {
            "id": "User.addMark.0",
            "keys": "shift+\\"
        },
  • When I switched to a new layout, WT kindly converted the config keys to the physical keys of that layout that would've produced the same character if pressed.
  • When I made further changes while that layout was still active, WT persisted those physical keys to the config, as if I entered them manually, in the process losing the knowledge that those are not the keys I started from.

This, of course, can manifest in other, more probable scenarios: "switch the layout, add a new action, save, some key in the other layout is now broken" etc.

What can be done:

Mapping of keys between different layouts is not 1 to 1. It's one to many, or many to one, or many to many, or to none, can be anything since MSKLC exists, so conceptually it probably will always stay broken to some extent.

But maybe at least:

  • Try to not overwrite the keys the user have not touched while adding, removing, editing something else?
  • Fix those "Open default settings file (JSON)" and "Open settings file (JSON)" coming out of the blue?

Activity

  1. added
    Issue-BugIt either shouldn't be doing this or needs an investigation.
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    on Oct 16, 2025
  2. kdt523 commented on Oct 17, 2025

    @kdt523
  3. lhecker commented on Oct 17, 2025

    @lhecker
    Member

    No, but you can work on it if you'd like.

  4. DHowett commented on Oct 22, 2025

    @DHowett
    Member

    PankajBhojwani You're not here in triage but I am assigning this one to you as our Actions Person 🙂. Enjoy the new bug!

  5. added
    Area-SettingsIssues related to settings and customizability, for console or terminal
    and removed
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    on Oct 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Area-SettingsIssues related to settings and customizability, for console or terminalIssue-BugIt either shouldn't be doing this or needs an investigation.Priority-3A description (P3)Product-TerminalThe new Windows Terminal.

Type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions