Make `/ide` command settings persistent via `/config`
Feature Request
Problem
The /ide command settings don't persist between Claude Code sessions. Users who prefer to disable IDE integration (e.g., VSCode integration) have to manually disable it every time they start a new session.
Proposed Solution
Move IDE integration settings to the /config command so they persist across sessions, similar to other configurable preferences.
Use Case
- User prefers to use Claude in VSCode but dislikes the integration features
- Currently needs to run
/ide disable(or equivalent) every session - Would prefer to set this once via
/configand have it remembered
Expected Behavior
/configshould include IDE integration preferences- Settings should persist across Claude Code sessions
- Users shouldn't need to reconfigure the same preferences repeatedly
Additional Context
This would improve the user experience by reducing repetitive configuration tasks and making the tool more predictable for users with specific IDE preferences.
I found a solution to launch claude via a small wrapper that removes the env vars it uses to detect VScode.
Adding the following alias/command works for me as a stopgap for now.
# ~/.zshrc or ~/.bashrc
function claude-noide() {
env -u VSCODE_PID -u TERM_PROGRAM -u VSCODE_IPC_HOOK_CLI claude "$@"
}
How did you determine those environment variables were responsible for the VS Code detection?
I'm interested in a variant of what the OP originally mentioned, but almost a functional opposite.
I launch Ghostty (terminal) with claude from WebStorm (IntelliJ) and I want it to be able to automatically connect to the source IDE.
I've tried playing with a bunch of variations like passing the CLAUDE_CODE_SSE_PORT and trying to override TERMINAL_EMULATOR and __CFBundleIdentifier and so forth to try to trick claude into thinking it's in the IDE context and should auto connect, but nothing has worked.
I see the /ide command shows a /ide [open] suggestion like it accepts a parameter, but I haven't seen any documentation about what the open parameter actually does or what valid values are.
Big +1 to this – I find the IDE extension distracting as it takes away from the minimalist, low-level style I initially fell in love with. For example: there are many circumstances when I don't want claude code to infer what file I'm looking at or act on linter errors. It feels like it's clobbering the context with unnecessary information I don't plan on acting on, and I anecdotally feel like it causes degraded performance b/c of this.
It would be great if we could add a setting to .claude/settings.local.json to persist this as I currently have to disable it at the start of every session:
{
"ide": false
}