You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Add /reloadSettings command to reload configuration without restart #5513
My ideal solution here would be that claude just listens to changes in its settings file and reloads them automatically (this is how Alacritty works) but I suppose if I could call something like claude -p "/reloadSettings" and have that trigger reloads in all active claude processes that'd be fine too (this is similar to how I have to do it in tmux).
This would eliminate the context-loss friction when building custom Claude Code workflows and make the platform significantly more developer-friendly for
extensibility.
+1 for this feature with expanded scope! 🚀
Reacted by Dekadinious, Larah Vasquez, noamr-blip and shine-on-me
It is only sensible to want this for anyone working on hooks. The number of restarts I have had to do is insane, just fiddling with syntax and parsing data. Being able to replay events would be pretty cool as well. So each time I want to test a hook, I have to do more stuff to make that data for testing.
Use case: Dynamic MCP server activation mid-session
My workflow requires MCP servers to be disabled at startup and activated on-demand during an interactive session based on specific events or conditions.
Current limitation:
MCP servers defined in settings.json are loaded at process start and cannot be added, removed, or modified mid-session. There's no way to:
Start a session without MCP servers
Dynamically expose an MCP server to Claude when needed
Deactivate an MCP server during a session
Current workaround (and why it's problematic):
I load MCP servers in settings.json but disable them at a lower level in my system. The problem: Claude still sees the MCP server as available and may attempt to use it, resulting in errors or confusing behavior. This creates a poor UX—Claude tries to use a tool, fails, and has to recover from an unexpected error.
Why proper dynamic activation matters:
Security: expose tools only when explicitly needed
Performance: avoid loading unnecessary MCP servers at startup
Clean UX: Claude should only see tools that are actually available, not disabled stubs that return errors
Proposal: Beyond the /reloadSettings command, consider supporting a programmatic trigger for settings reload—e.g., via hook action responses. This would enable true dynamic MCP server management: servers could be cleanly added or removed from Claude's available tools mid-session, without errors or workarounds.
The manual /reloadSettings command is a good baseline, but a programmatic trigger would unlock workflows where MCP servers are activated only when genuinely needed.
My issue was closed for inactivity here, but I think this one could benefit from it also.
Add file-watcher on settings that would automatically apply changes - specifically theme changes.
Use-case: I have a script that modifies background of my terminal, desktop session and other programs according to my choice. I update configs for Alacritty, VS Code and others and they immediately apply my theme choice. Unfortunately changing background color in Alacritty makes Claude Code diff viewer unreadable.
+1 .. yes! .. just got in to claude code and tuning the settings. I don't want to have to restart and lose chat context when I realize I want to add some tunings so permissions aren't asked every few seconds for common and safe commands.
Running 3-4 parallel Claude Code sessions (one per project/feature). When I deploy
an updated hook from my config repo to ~/.claude/, I have to restart every session
to pick it up — even sessions that have nothing to do with the change.
A /reload-hooks command (even session-scoped) would solve this without needing
full auto-reload infrastructure.
Running 3-4 parallel Claude Code sessions (one per project/feature). When I deploy an updated hook from my config repo to ~/.claude/, I have to restart every session to pick it up — even sessions that have nothing to do with the change.
A /reload-hooks command (even session-scoped) would solve this without needing full auto-reload infrastructure.
@twhitteberry Did you try entering the /hooks menu? I've done that before to refresh hooks. I think the idea is it doesn't reload until you've viewed them. I've bumped into this too while doing a lot of hook work.
Workaround: /clear reloads settings without losing your session.
When you run /clear, Claude Code re-reads all settings files (user, project, enterprise) and CLAUDE.md files as part of re-initializing the conversation. Your conversation history is cleared, but any work done (file changes, git commits) persists.
Workflow for iterating on hooks/settings:
Edit ~/.claude/settings.json (or project-level)
Run /clear in Claude Code
Settings are now active — test your changes
This is faster than a full restart since it skips the Node.js initialization step.
For hook development specifically, you don't even need /clear — hooks are re-read from disk on every invocation. If you change a hook script (e.g., ~/.claude/hooks/syntax-check.sh), the next tool call that triggers that hook will use the updated script. You only need /clear when changing the hook configuration in settings.json (adding/removing hooks, changing matchers).
Part of the pain here is editing JSON files blind and restarting to see if it worked. A visual dashboard that shows all your settings across every scope (global, workspace, project) side by side can help reduce the trial-and-error cycle.
I'm building one that lets you see your full Claude Code config — memories, skills, MCP servers, hooks — organized by scope hierarchy. You can move items between scopes with drag-and-drop and delete things directly, instead of manually editing JSON and restarting to verify.
Not exactly a /reloadSettings, but claude-restart adds a /restart command that exits and auto-resumes the session. Since the process restarts, settings, hooks, and MCP connections are all reloaded. Might help as a workaround.
workaround : open /config, Change color, save, Revert color, save, Boom you are using custom edited settings(color change only affecting theme in json so your edits to there persist)
Since #15858 and #30427 were both closed as duplicates pointing here: does this cover CLAUDE.md / project memory files too, or is the scope settings.json only? Title and description only mention settings.json.
CLAUDE.md gets edited constantly during active work, and a stale version fails silently — Claude keeps following outdated instructions with no error or warning, so you don't notice until something goes wrong downstream.
Would help to know either way, so people who came from #15858/#30427 know whether to keep watching this issue or if a separate one is needed for CLAUDE.md.
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.
Activity
christiangenco commentedon Aug 17, 2025
I want this for automatic theme switching when my system changes from light to dark mode or vice versa.
On macOS I wrote a system for updating the themes of my terminal apps with current system theme when the theme changes. I have this sytem working with the
~/.claude/settings.jsonfile to update Claude Code's theme but currently Claude has to be reloaded for the change to take effect.My ideal solution here would be that claude just listens to changes in its settings file and reloads them automatically (this is how Alacritty works) but I suppose if I could call something like
claude -p "/reloadSettings"and have that trigger reloads in all active claude processes that'd be fine too (this is similar to how I have to do it in tmux).jenko commentedon Oct 29, 2025
Expand scope to include slash commands and hooks
I'd love to see this
/reloadSettingscommand expanded to also reload:.claude/commands/*.md.claude/hooks/*Use Case
When developing custom slash commands and hooks, the current workflow is painful:
.claude/commands/dogit_merge.md)This makes iterative development of custom workflows incredibly tedious.
Proposed Enhancement
A comprehensive
/reloadSettingscommand that refreshes:.claude/settings.json) - already covered by this issue.claude/commands/*.md) - addition.claude/hooks/*) - additionAll while preserving conversation context.
Example Output
User: /reloadSettings
Claude: 🔄 Reloading Claude Code configuration...
✅ Reloaded settings.json
✅ Reloaded slash commands:
✅ Reloaded hooks:
Configuration successfully reloaded. Context preserved.
This would eliminate the context-loss friction when building custom Claude Code workflows and make the platform significantly more developer-friendly for
extensibility.
+1 for this feature with expanded scope! 🚀
efrazier commentedon Oct 30, 2025
It is only sensible to want this for anyone working on hooks. The number of restarts I have had to do is insane, just fiddling with syntax and parsing data. Being able to replay events would be pretty cool as well. So each time I want to test a hook, I have to do more stuff to make that data for testing.
memetican commentedon Nov 3, 2025
+1 and glad to see I wasn't going crazy.
rcgalbo commentedon Nov 10, 2025
+1+1
kieranklaassen commentedon Nov 24, 2025
Yes, please.
VangVang commentedon Dec 3, 2025
+1
Dekadinious commentedon Dec 5, 2025
+1
Eimitfi commentedon Dec 17, 2025
Use case: Dynamic MCP server activation mid-session
My workflow requires MCP servers to be disabled at startup and activated on-demand during an interactive session based on specific events or conditions.
Current limitation:
MCP servers defined in
settings.jsonare loaded at process start and cannot be added, removed, or modified mid-session. There's no way to:Current workaround (and why it's problematic):
I load MCP servers in
settings.jsonbut disable them at a lower level in my system. The problem: Claude still sees the MCP server as available and may attempt to use it, resulting in errors or confusing behavior. This creates a poor UX—Claude tries to use a tool, fails, and has to recover from an unexpected error.Why proper dynamic activation matters:
Proposal: Beyond the
/reloadSettingscommand, consider supporting a programmatic trigger for settings reload—e.g., via hook action responses. This would enable true dynamic MCP server management: servers could be cleanly added or removed from Claude's available tools mid-session, without errors or workarounds.The manual
/reloadSettingscommand is a good baseline, but a programmatic trigger would unlock workflows where MCP servers are activated only when genuinely needed.cyrusmg commentedon Jan 7, 2026
My issue was closed for inactivity here, but I think this one could benefit from it also.
Add file-watcher on settings that would automatically apply changes - specifically theme changes.
Use-case: I have a script that modifies background of my terminal, desktop session and other programs according to my choice. I update configs for Alacritty, VS Code and others and they immediately apply my theme choice. Unfortunately changing background color in Alacritty makes Claude Code diff viewer unreadable.
#6236
dooferorg commentedon Jan 16, 2026
+1 .. yes! .. just got in to claude code and tuning the settings. I don't want to have to restart and lose chat context when I realize I want to add some tunings so permissions aren't asked every few seconds for common and safe commands.
richardkmichael commentedon Jan 17, 2026
@dooferorg Use
claude --continue2 remaining items
privacyguy123 commentedon Feb 13, 2026
+1million
lakshit-rubrik commentedon Mar 1, 2026
+1 Trillion. Must have feature before IPO
twhitteberry commentedon Mar 11, 2026
Use case: multi-session + active hook development
Running 3-4 parallel Claude Code sessions (one per project/feature). When I deploy
an updated hook from my config repo to
~/.claude/, I have to restart every sessionto pick it up — even sessions that have nothing to do with the change.
A
/reload-hookscommand (even session-scoped) would solve this without needingfull auto-reload infrastructure.
richardkmichael commentedon Mar 11, 2026
@twhitteberry Did you try entering the
/hooksmenu? I've done that before to refresh hooks. I think the idea is it doesn't reload until you've viewed them. I've bumped into this too while doing a lot of hook work.yurukusa commentedon Mar 15, 2026
Workaround:
/clearreloads settings without losing your session.When you run
/clear, Claude Code re-reads all settings files (user, project, enterprise) and CLAUDE.md files as part of re-initializing the conversation. Your conversation history is cleared, but any work done (file changes, git commits) persists.Workflow for iterating on hooks/settings:
~/.claude/settings.json(or project-level)/clearin Claude CodeThis is faster than a full restart since it skips the Node.js initialization step.
For hook development specifically, you don't even need
/clear— hooks are re-read from disk on every invocation. If you change a hook script (e.g.,~/.claude/hooks/syntax-check.sh), the next tool call that triggers that hook will use the updated script. You only need/clearwhen changing the hook configuration insettings.json(adding/removing hooks, changing matchers).rent-a-developer commentedon Mar 18, 2026
+1
ithiria894 commentedon Mar 21, 2026
Part of the pain here is editing JSON files blind and restarting to see if it worked. A visual dashboard that shows all your settings across every scope (global, workspace, project) side by side can help reduce the trial-and-error cycle.
I'm building one that lets you see your full Claude Code config — memories, skills, MCP servers, hooks — organized by scope hierarchy. You can move items between scopes with drag-and-drop and delete things directly, instead of manually editing JSON and restarting to verify.
We just launched and are actively building towards solving more of these config workflow problems — give us a ⭐ to follow along: https://github.com/mcpware/claude-code-organizer
yacb2 commentedon Mar 23, 2026
Not exactly a
/reloadSettings, but claude-restart adds a/restartcommand that exits and auto-resumes the session. Since the process restarts, settings, hooks, and MCP connections are all reloaded. Might help as a workaround.docs: tell users to restart claude after installing the hook
Pou-xlover commentedon Jul 7, 2026
workaround : open /config, Change color, save, Revert color, save, Boom you are using custom edited settings(color change only affecting theme in json so your edits to there persist)
wolf3i commentedon Aug 6, 2026
Since #15858 and #30427 were both closed as duplicates pointing here: does this cover CLAUDE.md / project memory files too, or is the scope settings.json only? Title and description only mention settings.json.
CLAUDE.md gets edited constantly during active work, and a stale version fails silently — Claude keeps following outdated instructions with no error or warning, so you don't notice until something goes wrong downstream.
Would help to know either way, so people who came from #15858/#30427 know whether to keep watching this issue or if a separate one is needed for CLAUDE.md.
bcherny commentedon Aug 17, 2026
This is covered in a recent release: Claude Code now watches your settings files (user, project, local, managed) and reloads them when they change, so edits to permissions, hooks, and most other keys apply to the running session without a restart or a command. A couple of keys (
model,outputStyle) still need/modelor a restart. Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md — docs: https://code.claude.com/docs/en/settings#when-edits-take-effect🤖 Generated with Claude Code
github-actions commentedon Oct 7, 2026
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.