Add sctx claude enable/disable commands to manage hook settings#3
Merged
Add sctx claude enable/disable commands to manage hook settings#3
Conversation
gregology
added a commit
that referenced
this pull request
Mar 9, 2026
Add sctx claude enable/disable commands to manage hook settings
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
sctx claude enableandsctx claude disablecommands.claude/settings.local.jsonso users don't have to manually copy-paste JSONWhy
Right now, setting up sctx with Claude Code means copying a block of JSON from the README into your settings file. It's fiddly. Easy to get wrong. And if we ever change the hook config (new tool names, different matchers), everyone has to manually update their JSON.
A first-class command fixes that.
sctx claude enablein your project directory and you're done.Approaches considered
We looked at three options:
Direct JSON merge (single function) - Just a standalone
Enable()function that reads/writes the JSON file. Simple, but the merge logic would live outside the adapter package, disconnected from the hook definition it's supposed to match. If we ever add Cursor or Windsurf support, we'd end up duplicating the same pattern with no shared structure.Generic JSON patcher - A declarative patching engine where adapters define their settings as data, and a generic patcher applies them. Cool in theory. Way too much machinery for one settings file and one agent. We'd be building a mini-framework with exactly one consumer.
Adapter pattern (chosen) - The hook definition and the setup logic live together in
internal/adapter/, right next to the existing hook handler code. This means the hook config that gets written to settings.json is defined in the same package that actually processes those hooks. Single source of truth. If we add another agent later, it gets its own setup file in its own adapter package following the same pattern.We went with the adapter approach because it matches the project's existing architecture without adding unnecessary abstraction. The cost over the "single function" approach is basically one extra file. The benefit over the generic patcher is we didn't spend a week building infrastructure we don't need.
Behavior notes
"Already enabled" and "not enabled" are informational messages, not errors. Running
sctx claude enabletwice exits 0 both times. The commands preserve any existing settings and hooks in the file - they only touch the sctx-specific entries.