IntelliJ Terminal Setting "Use Option as Meta key" is automatically enabled when running Claude in IntelliJ

[PaulWen]

Bug Description Running "claude" in the IntelliJ terminal with the Claude Code extension installed results in the activation of the setting "Tools > Terminal > Use Option as Meta key". Using a German keyboard, I always keep this deactivated, as I am otherwise unable to type symbols like "@". With the current behavior, I cannot type "@" to reference files without updating the settings first whenever I reopen claude.

Environment Info

• Platform: macos
• Terminal: intellij
• Version: 1.0.3
• Feedback ID: 07522019-9d2b-424b-95e2-0f8a048a5b09

[michaelhaessig]

Just hit the same issue - thanks @PaulWen for mentioning it.

[hackyon-anthropic]

Looking into this now! We are using the Option key to add new lines with Option+Enter, which unfortunately overrides the setting.

We plan to add a setting in Settings > Tools > Claude Code [Beta] in the next update to disable this behavior. We will also try add some support for using Shift+Enter instead to add new lines (but unfortunately the Shift+Enter option doesn't always work either).

The next update should be coming soon!

[joshualyon]

We will also try add some support for using Shift+Enter instead to add new lines (but unfortunately the Shift+Enter option doesn't always work either).

Being able to use shift+enter consistently when switching between VS Code, our terminal app of choice (Ghostty), and IntelliJ IDEs would be fantastic for usability.

I find shift+enter much more natural and intuitive compared to option+enter and I struggle with inadvertently sending a message early in IntelliJ as I'm so accustomed to the shift variant.

Edit: I don't know what options are available to IntelliJ plugin developers for launching things, but I wanted to share that the Classic terminal engine seems to respect shift+enter ... but after moving Claude's terminal session to the Editor pane, if you then move it to a different location (eg. split right), shift+enter stops working which is a pain if you wanted to have Claude in a side-panel or floating pane so you could continue to reference it while switching between files in the IDE.

[hackyon-anthropic]

Thanks @joshualyon!

Yes, we've actually added some support for using Shift+Enter for new lines in the newest versions of the plugin!

However, due to some API limitations, it doesn't work for all versions of the terminal (namely, the Reworked 2025 terminal engine). You should still be able to use Alt+Enter or Opt+Enter for new lines in those environments.

The Reworked 2025 terminal is still under development, so it's possible that JetBrains will eventually expose the API for us to hook up Shift+Enter. We'll keep an eye out and check back in new updates!

[cpdomina]

Using classic terminal solves part of the issue, but as @joshualyon mentioned, things get messed up again if you move the terminal around (e.g., second monitor).

There's an easy fix: call claude with the terminal of your choice (iTerm2 in my case), and connect to the IDE manually using /ide

[geirsagberg]

I am using Reworked (2025) terminal and Shift + Enter works in the latest Claude Code, regardless of what I do with the window. Might be safe to not touch the "Use Option as Meta key" toggle now?

[schmitz-chris]

I use a German keyboard layout and have disabled Use Option as Meta key in the IntelliJ settings. As soon as I start claude code in my IntelliJ terminal (regardless of Classic or Reworked 2025), the setting is reactivated. To rule out a bug in the UI, I manually added the value to the file Library/Application Support/JetBrains/IntelliJIdea2025.2/options/terminal.xml
<option name="useOptionAsMetaKey" value="false" /> As soon as I start one or more terminals, everything works fine. If I start claude code in one of these terminals, the value is immediately set to TRUE. This is incredibly frustrating in my daily work and I hope a solution to the problem can be found quickly. This affects German and Nordic keyboard layouts.

[shanecp]

For anyone wondering why it sometimes works and sometimes doesn't:

• If you open a terminal window in IntelliJ, and type 'claude' - Shift + Enter won't work, but Alt + Enter will work.
• If you open Claude Code with shortcut (Cmd + Esc) or button, Shift + Enter will work as expected.
• If you use iTerm externally, open claude code and then connect to IDE, Shift + Enter will work as expected.

[lukens]

For anyone wondering why it sometimes works and sometimes doesn't:

• If you open a terminal window in IntelliJ, and type 'claude' - Shift + Enter won't work, but Alt + Enter will work.
• If you open Claude Code with shortcut (Cmd + Esc) or button, Shift + Enter will work as expected.
• If you use iTerm externally, open claude code and then connect to IDE, Shift + Enter will work as expected.

Thank you for this!. Is there a way to get more than one instance of Claude code up using the shortcut/button though?

[adamdrzewiecki]

I don’t know if it’s relevant, but I noticed that when I launch Claude Code in the terminal (Reworked 2025) and then uncheck the “Use Option as Meta key” option, both Cmd + Enter and Polish characters (e.g., Cmd + A, Cmd + L) work correctly.

[steinnes]

Shift+enter works fine for me in claude code to add newlines to my messages without sending them, and I feel like that is the widely and universally accepted key combination to produce that behaviour. Is this bug because it's also possible to use option+enter to produce newlines? Sure feels like a a very minor convenience feature is causing a lot of pain for us german/nordic keyboard users.

I've been quietly (and sometimes not so quietly) cursing PyCharm and its new shell for this issue for a couple of months now 😅

[pkernevez]

Still unsolved ? How can we reference files without this behavior ?

[steinnes]

Still unsolved ? How can we reference files without this behavior ?

I've stopped running claude code from within the PyCharm terminal, instead I just use claude code in an iTerm next to it.

[villesau]

The behavior is very similar on macos native terminal too. You enable "Use Option as Meta key" and you loose @ etc characters. You disable it, you loose possibility for new lines.

[orcasai]

still this option has auto-enable, terrible and in any intellij plattform it does make claude code useless. On

after restart, its enabled again. Terrible to work with claude code in any intellij editor cause of this bug.

@ symbols etc does not work in claude code cause of the overwritten option key with the meta functionality ...

Why are you not fixing it? should have a huge priority in your ticket system!

[hackyon-anthropic]

We've introduced a way to disable this behavior within the Claude Code settings.

First, disable the Enable using Option+Enter for multi-line prompts in the Claude Code settings:

Then, disable the Use Option as Meta Key setting in Terminal:

Please give that a spin and see if that helps uncapture the option setting.

Sorry for the churn, but there's been multiple versions of the IntelliJ terminal and they each have different APIs (and also many different OS platforms, keyboard layouts, and other settings/configurations). That's why sometimes the shift+enter key works, and sometimes the option key doesn't work.

We try to provide different options that will allow users to configure a setting, but it's not always entirely obvious. We have a small blurb about it in the docs, but thanks for everyone's feedback, we'll look into others ways to see if we can make this configuration work (and also to surface it more prominently in troubleshooting).

[orcasai]

Thx, with this configuration in combination (both disabled) it works. Great moment cause of the new Claude Code Update including new Sonnet 4.5 🤌

[logemann]

Can confirm it works now with the help of the claude setting. This was a very weird bug which has been bothering me for weeks now.

[hackyon-anthropic]

Thanks everyone! Will try to look into making this more intuitive (tracking in another internal ticket), but closing this for now.

[github-actions[bot]]

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.