Feature Request: Add /reloadSettings command to reload configuration without restart

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.json file 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).

## Expand scope to include slash commands and hooks

I'd love to see this /reloadSettings command expanded to also reload:

• Slash commands from .claude/commands/*.md
• Hooks from .claude/hooks/*
• Pretty much anything that requires a restart

### Use Case

When developing custom slash commands and hooks, the current workflow is painful:

1. Create/edit a command file (e.g., .claude/commands/dogit_merge.md)
2. Test it in Claude Code
3. Find an issue or want to refine the behavior
4. Edit the command file
5. Restart entire Claude Code session (losing all context)
6. Re-explain the codebase and current work
7. Test again

This makes iterative development of custom workflows incredibly tedious.

### Proposed Enhancement

A comprehensive /reloadSettings command that refreshes:

• ✅ Settings (.claude/settings.json) - already covered by this issue
• ✅ Slash commands (.claude/commands/*.md) - addition
• ✅ Hooks (.claude/hooks/*) - addition

All while preserving conversation context.

### Example Output

User: /reloadSettings

Claude: 🔄 Reloading Claude Code configuration...

✅ Reloaded settings.json
✅ Reloaded slash commands:

• /dogit
• /dogit_merge
• /dogit_del

✅ Reloaded hooks:

• PostToolUse: ruff_check.sh

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! 🚀

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.

+1 and glad to see I wasn't going crazy.

+1+1

Yes, please.

+1

+1

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.

https://github.com/anthropics/claude-code/issues/6236

+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.

@dooferorg Use claude --continue

Adding a specific case: Resumed sessions don't pick up new MCP servers

Ran into this while setting up a new project with an existing MCP server.

Scenario:

1. Add new MCP server to ~/.claude/settings.json
2. Start fresh session in Project A → MCP tools work
3. Later, resume an old session in Project B (created before MCP was configured)
4. MCP tools not available in resumed session

Workaround: Start a fresh session instead of using --continue/--resume.

The MCP config appears to be "baked in" at session creation time. Would be great if /reloadSettings (or session resume) picked up current MCP configs.

+1

+1million

+1 Trillion. Must have feature before IPO

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 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.

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 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:

1. Edit ~/.claude/settings.json (or project-level)
2. Run /clear in Claude Code
3. 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).

+1

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

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)