[BUG] `/terminal-setup` should ask for permission, not forgiveness

Status Closed — not planned
Maintainer reply None cached
Activity 8 comments · opened Oct 1, 2025 · closed Feb 7, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

It was suggested that I run /terminal-setup, so I did. Without telling what it did, claude created .wezterm.lua. This shadowed .config/wezterm/wezterm.lua thereby reverting my customizations. It took a while to figure out what had happened.

What Should Happen?

Claude already knows how to show me diffs and ask if they're OK, it should do that in this case so I can say "no" instead of having to go revert the file myself.

Error Messages/Logs

Steps to Reproduce

  1. Run /terminal-setup
  2. Be suprised about what was changed

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.1

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

8 Comments

darksinge · 1 year ago

I don't use nix, but was still unpleasantly surprised to discover all of my custom key bindings/assignments defined in my .wezterm.lua was overridden by changes introduced after running /terminal-setup.

imo, /terminal-setup should respect existing configurations.

MatrixManAtYrService · 12 months ago

In the case of wezterm, there's a whole precedence system for how to find the config file: https://wezterm.org/config/files.html

In my case the workaround was to simply delete the .wezterm.lua which claude had created. This caused my actual config to be found instead. I realize that it might be challenging to support merging claude's configs with a user's custom configs, so in the near term "ask first" is all I'm shooting for.

mikewaters · 10 months ago

+1 here; I've been going nuts trying to figure this out, the config dropped in my CC is:

config.keys = {
  {key="Enter", mods="SHIFT", action=wezterm.action{SendString="\x1b\r"}},
}

I've appended this to my actual config out of an abundance of caution, and removed the offending file. Note this requires a restart of wezterm - which can be a PITA - and so you should background/tmux anything you need to persist.

github-actions[bot] · 9 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

MatrixManAtYrService · 9 months ago

Just retested with 2.0.76 (current latest). This still happens.

It is explicit about what it's doing.

  ⎿  Installed WezTerm Shift+Enter key binding
     You may need to restart WezTerm for changes to take effect
     See /Users/me/.wezterm.lua

But users are unlikely to be thinking about the fact that creating this file will deactivate an existing config at ~/.config/wezterm/wezterm.lua (it could be any of these). If they don't restart their terminal immediately, they're likely to have forgotten about this change, so when they eventually do, their other configs will be missing, and they won't know what to do.

A better approach would be:

  1. ask wezterm which config file is in use (like so)
  2. make a temporary copy of that file and add the new config
  3. show the user a diff including the change and offer a choice:
  • update the original with this change
  • cancel the change
  • open an editor to modify the change by hand

Claude code is already good at this kind of thing 😄, so 🤞 it's not to hard to be as polite about editing the user's config as you already are about editing the user's code.

github-actions[bot] · 8 months ago

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

marcindulak · 8 months ago

This issue was closed incorrectly despite recent human comments. This behavior of the bot is reported at https://github.com/anthropics/claude-code/issues/16497. Please upvote that issue, so maybe it gets noticed.

github-actions[bot] · 8 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.