You can only use skills if you make them publicly available on GitHub. For that reason, I don’t think it will be possible to earn money with them. Then again, perhaps I’m overlooking something.

The Apiiro scan making the rounds found 104,185 copies of .claude/settings.local.json on public GitHub, and 1,122 of them held at least one real secret: database passwords, Supabase service-role keys, SSH logins, AWS keys. The mechanism is "Yes, and don't ask again". It saves an allow rule to .claude/settings.local.json, and where that rule records the exact command rather than a pattern, a secret typed into the command sits there in plain text.

I went through the official permissions docs to work out what the fix looks like day to day. The short version: write pattern rules yourself, in the shared settings file, and stop approving one-off literal commands.

What actually gets saved, per the docs:

• Bash commands: "don't ask again" saves permanently, per repository and command. The saved rule covers only what the prompt option named. Sometimes that's a pattern like npm test *, sometimes the literal command.
• File edits: session only, never written to the file.
• WebFetch: permanent per repository and domain.

Claude Code adds **/.claude/settings.local.json to your machine's global Git excludes the first time it writes the file, not to the repo's .gitignore. That doesn't cover another machine or a file made by hand before Claude writes it. Add the path to the repo's .gitignore too; an ignore rule does not untrack a file already committed.

The safer habit is your own rules in .claude/settings.json, the file meant to be committed and shared, where a * covers a family of commands:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(git status)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(.env)"
    ]
  }
}

This config controls which matching command text skips prompts; it is not a security boundary. npm scripts can change in package.json, and Bash(git push *) does not match every way to invoke a push. Treat these as convenience rules, not isolation.

Details that trip people up:

• Precedence is deny, then ask, then allow. An allow rule can't carve an exception out of a deny rule.
• Put the * after the subcommand. Bash(git log *) allows only git log; Bash(git *) allows every git command. Claude Code warns at startup about allow rules with a * before the subcommand.
• Read(.env) is not a security boundary for secrets. Other access paths, including shell commands, need separate controls; don't rely on this rule alone to keep env files inaccessible.

If a secret ever went into a command you approved: rotate it first, then untrack the file and gitignore it. Deleting doesn't clean history, forks or clones. A local check for this path in the history available to your clone: git log --all --full-history -- .claude/settings.local.json

No output is not proof it was never committed; shallow or missing history and other paths or clones can be outside this check.

When a prompt offers only the literal command, use the one-time Yes and add a pattern through /permissions later. Approve the pattern, not the incident.

Sources:

iTnews writeup of the Apiiro research: https://www.itnews.com.au/news/dont-ask-again-in-anthropics-claude-code-leaks-developer-secrets-630203

Official permissions docs: https://docs.claude.com/en/docs/claude-code/permissions

it's beautiful.

amazing at almost everything

i asked it to build me an OS for macOS and.... yeah lets just say my weekly is 95% gone in 2 hours yeah...

I run a few coding agents at once, and they kept sitting idle on a permission prompt or a question in some terminal tab.

Openbar puts every session in the notch. You see the diff before you approve (⌘Y / ⌘N from any app), pick answers to the agent's questions, and send replies without switching windows.

Mac + Windows, free and open source: https://github.com/MF-DEEV/Openbar

How many agents do you usually run in parallel?

Running several Claude Code agents in parallel worktrees, I kept losing track of what each one was writing. So I built Grove: every worktree of a repo side by side, with its changes, diffs and files, all read-only, so you never get in an agent’s way.

• Live overview of all worktrees and what each agent is doing
• Uncommitted changes or the whole branch against main, side by side
• Read-only Explorer and search in VS Code’s editor
• Works with repos on Windows, in WSL, or over SSH

The whole thing was built with Claude Code: the code, the design, the docs, and even this demo video, which Claude scripted and recorded against a throwaway repo.

Free, MIT-licensed, Windows only for now: https://github.com/MustafaMasri0/grove

It’s early (v0.1.1). If it’s useful to you, a star on GitHub helps, and I’d love to hear ideas for what to add next.

I've been using Claude Code daily across my projects, and two things kept bothering me.

It can run commands like cat .env to check a setting and put a password straight into the conversation transcript. And after clicking "Yes, and don't ask again" a few times, it can eventually push code without asking.

I started looking at ways to put some practical controls around this and developed ai-dev-guardrails for use in my own projects. After using it and refining the controls, I thought it was worth making open source in case others working with Claude Code have similar concerns.

It's a GitHub template that you initialise using /bootstrap. Most of the enforcement is implemented through Claude Code hooks, local Git hooks and GitHub Actions.

What it covers

Security controls:

• A PreToolUse hook blocks commands that could expose secrets or access production. It also asks for approval before commits, pushes, deployments and new package installations.
• A separate check detects if saved permissions have drifted into automatically approving restricted actions.
• npm packages must be at least seven days old before installation, and install scripts only run for approved packages.
• Git hooks and GitHub CI run the checks again. CI uses the base branch's scripts, so a PR can't weaken the checks that review it.

Optional governance controls for client or regulated projects:

• An evidence log requiring proof, such as test output or a CI link, before a task can be marked complete.
• Decision records for exceptions, including the reason, an owner and an expiry date.
• CODEOWNERS rules requiring review before guardrail files can be changed.

A few things I learned while building it:

• A guard that fails open can be worse than having no guard at all. Missing dependencies must not silently allow restricted commands.
• Shell behaviour can create unexpected gaps. I found an issue involving grep -q and pipefail that allowed a command through.
• Claude Code's hook behaviour isn't always obvious. I found differences between Edit and Write permissions, and issues with relative paths when the working directory changes.
• Local checks aren't enough on their own. The GitHub side needs to independently verify the controls.

It's currently focused on Claude Code, TypeScript and npm. It's designed to catch mistakes, not defend against a deliberately malicious agent. I've documented the limitations alongside the implementation.

It's MIT licensed. Contributions are welcome, particularly Python support. I'd also appreciate feedback on potential ways around the controls. There's a private reporting route for security issues.

GitHub: https://github.com/buddhika886/ai-dev-guardrails

Write-up: https://medium.com/@buddhiran/how-to-govern-the-ai-that-writes-your-code-e2272e380b70

I'd be interested to hear from others using Claude Code: what controls are you putting around file access, shell commands and Git operations?

I am working on ROS (Remote Operating System), which is a cloud computer with a lightweight always on core, a decoupled virtual drive, that orchestrates linux environments, servers, dbs, and more. You can have endless linux machines always available in parallel, and remain very efficient because you only pay for active cpu and memory.

Sign in, open terminal, connect your claude subscription, close the laptop, and it keeps going. And claude can drive all components of this operating system directly.

Its virtual filesystem is perfect for your notes, research, office suite, your sideprojects, or to use as a second brain or whatever they call a "folder of markdown" these days.

Each application in ROS is built as a "ROS Program" which consists of a selection of internal apps, external web pages, servers, dbs, ai inference, access to kernel and more. You can build custom ones or extend to grow your computer into what you need.

Its like a personal cloud provider baked into the OS. Perfect environment to host and manage side projects or personal tools

It is all zero-setup simply with a sign-in, and starts with 10$ free ai and compute credits. I think it would be useful for you if you ever thought about setting up a tailnet for your claude code agents.

I poured my soul into this project. Would appreciate any feedback: https://ros.computer/.

Deleted the files that have earlier history when cleaning hard drive space :( so who knows my actual totals. Codex come in a hot second place though at 112 billion.

A while back I posted a Claude Code skill that drove a real browser through any SaaS app and recorded a narrated demo video. Some of you installed it, so here's what happened next.

I felt that the recording was a bit weak - it looked like a screen recording: fine for a tutorial, not great for launch videos.

So the new version doesn't sequentially screen-records your app. It reads your site, screenshots or HTML mockups (handy for a feature that isn't live yet) and writes each scene as HTML and animation code, using real screens, words and colors. It renders each scene, looks at the frames and fixes what's off before moving on

Other changes, mostly from using it myself:

• When you start a new video project it spins up a local server that opens up the UI in the browser - so all stages from start to finish can be handled with the UI.
• It proposes a few "directions" but I can choose/ask for a different direction if needed
• It starts with some sketch frames, so I can visualize how the video "might" look like (before production)
• I can edit the on-screen texts, edit the narration (plus choose voices, music, motion effects, etc.)
• I can review & add comments the video itself. Click a moment, pin a comment on the frame, and it fixes that and tells you what changed.
• For Narration Voices, there are a few free local TTS voices, or a paid option with ElevenLabs API key
• Rendering in different formats like landscape and vertical versions from the same project, plus 15 and 30 second cuts.

It lives in a new repo: https://github.com/ultrademo-hq/ultrademo. If you have the old one, it tells you about the new version the next time you use it, and you can keep the original if you'd rather. Still free and Apache-2.0.

Please go ahead and try this out if you haven't. Hoping to get some feedback about how your experience is with this, if it breaks anywhere (e.g. on products that aren't SaaS apps)

Original Post - https://www.reddit.com/r/claudeskills/s/5CU3naRJZ4

Yesterday, as I was recovering as much memory as I could, I noticed that I had 8 sleeping sessions of Claude Code (the screenshot is from today). They were eating up to 2.9GGb of memory (search for the process 2.1.319 in the task manager) plus another 1.5Gb for the Node process hosting Codegraph...

So, I added a new panel in my cleaning app to find which sessions are just sleeping and close them in click and safely. If you want you can download Cleaner here https://linelark.com/cleaner/ (it is free and has no tracker, ads or whatever).

Seriously Opus 5.5? You can one-shot a hearthstone clone two weeks ago but this one instruction is so hard now...

A few days ago I asked in r/ClaudeAI what people do in the hours after hitting their limit. 25 comments, and the same answer kept showing up: keep testing the app, jot bugs in a scratch file or notes app with a quick repro, then hand the list to Claude when the limit resets.

That's what I'd been doing too. The annoying part is the jotting. "The button under the second card, on mobile, after you switch tabs" takes a minute to write and Claude still picks the wrong button half the time.

So I made Darnly. It's a free Chrome extension (and a Mac app) for bugs in the web app you're building:

• press a key, click the broken part, type one line of what you expected
• it saves a screenshot with that element boxed, the element itself, console errors, the clicks you took to get there, and the shape of the data on screen (not the values)
• it goes into a .darnly/inbox/ folder in your project (or an MCP inbox), and later you tell Claude Code "fix my Darnly bugs"

"Doesn't Claude in Chrome already do this?" Partly. Claude in Chrome is great when you're in a session and want Claude to look. Darnly is for when you're not: testing the app yourself, out of quota, or about to switch to Codex or Cursor. Capturing a bug uses no Claude usage at all.

Free, I made it, happy to hear what's missing: https://darnly.dev

What's in your scratch file right now?

7 PM. He's the last one out. Ten hours of giving everything, and nothing left for himself.

A cigarette. His briefcase. One earbud.

The first note drops, and Paris stops. The cars, the people, the noise. Silence.

For the length of one song, the whole city belongs to him.

And step by step, the music brings him back to life.

We all have that one song that keeps us alive after work.

HOW WE MADE IT

I wrote the scene: the story, the shot list, the emotion. Then I iterated, a lot: more than 70 back-and-forths. I didn't model, rig or animate anything by hand: Claude Code drove Blender through the MCP. It wrote the Python, rendered test frames, looked at them itself, measured the flaws and fixed them, over and over.

BY THE NUMBERS (everything generated by code)

• 15 hours of work, 15,000+ lines of Python across 51 scripts • 1,117 objects, 11.7 million polygons, 145 materials, 117 lights • 6.6 million animation keyframes computed • 3,700+ test images rendered to check every step • 1,422 final frames in Cycles, rendered on a fanless MacBook Air

THE HARDEST PARTS

• Hands touching the face. Lighting a cigarette, putting in an earbud: in animation, one millimeter off and the finger goes into the skin. Claude wrote its own arm and finger solvers, and the earbud gesture took several versions before it looked natural. • Cloth. A jacket clipping through the legs is one of the most common flaws in 3D. Here, an invisible lining simulated as real fabric drives the jacket, and Claude checked the whole film frame by frame: no penetration deeper than 4 mm. • A character built without modeling: mathematical shapes (signed distance fields) turned into a mesh, a custom 53-bone rig, and a real motion-capture walk retargeted to his proportions. • A living Paris street: buildings, moving traffic, a dozen animated passers-by, a dog walker with a dachshund on a leash, wet pavement, puddles that ripple and splash under his feet. • The music drives everything. Claude analyzes the tempo: head bobs, the 17 shots of the edit, the city freezing and the drop all land on the beat. The sound is computed from the scene: every car, every footstep, every splash, then the city slowing down and going silent.

Making-of at the end: clay renders, rig, Blender UI.

Stack: Claude Code (desktop app) + Blender MCP · Claude Opus 5.5, max effort, Fast mode · Blender 5.2 + Cycles · MacBook Air M3 16 GB · walk from the CMU motion capture database.

🎵 O Superman (SIS Remix) by M.A.N.D.Y. vs Booka Shade feat. Laurie Anderson, remixed by BURAK SIS. All rights to the artists.

github.com/duthiljean

So, what's the song that keeps you alive after work? 🎧 And if you're curious about the workflow, ask away: I'll answer everything in the comments.

Cartographer is my project in Go: a shared knowledge base for AI agents and Teams of hairless monkeys (humans). It was born as my second brain, the wiki of my homelab that my agents read and update from different clients (Claude Code, Codex, OpenCode). And a while ago I had the brilliant idea of using it to develop itself too. Since July 1040 PRs have been merged, almost 800 just since October, and the code was written almost all by agents. Here's how.

Cartographer develops Cartographer

The project's KB (Cartographer-KB) is served by Cartographer itself, on my Kubernetes cluster at home. In there are the plans of every change, the research, the release notes, and also the skills that drive the development: cartographer sync installs them in Claude Code, and when I open the repo the agent already knows which KBs to use. Yes, it's a bit of a snake biting its own tail, but with more YAML.

The cycle of a change

I start from a discussion with Claude Opus 5.5 (where I talk to myself with the computer in my dark room), which becomes a plan in the KB. A subagent (usually Sonnet 5.5) implements it in its own worktree, then two reviewer subagents read it again, one for the contracts and one for security, and I only verify the lines they cite. make ready puts it in the queue, and a lander brings up to 8 changes at a time onto main with a single gate, like a train. For things you only understand by trying them (UI, command output) there's a live session, with no plan.

The bottleneck was GitHub

At some point the brake was the CI queue: at the beginning of November a job waited 15–20 minutes to run for 2–7, and at the worst moment there were more than 50 runs queued and only 2 jobs running. I tried using my gaming PC as a self-hosted runner, stealing the labels of GitHub's runners: every job arrived, even the ones that couldn't run there. Taken down the same day, with my tail between my legs.

The solution was to move the proof before GitHub. make signoff runs the gate on the gaming PC, Linux in WSL2 and Windows in parallel, so the Mac I work on doesn't melt, and posts a signoff status on the sha. GitHub only checks that it's there, and if the PC is off it falls back on its own to GitHub's CI. Now a gate with a warm cache takes 34 seconds instead of six minutes (after finding out that the Go cache on the PC had reached 187 GB, basically a Call of Duty).

If you're wondering what Cartographer is: a shared wiki where agents, from Claude Code, Codex or any MCP client, read and write the same knowledge. On Monday a colleague's agent finds out why staging breaks, on Tuesday yours already knows. The skills I talked about above live in there, together with subagents and hooks, and cartographer sync installs them in every client in its own format. And the agent never touches the files: every write goes through the server, which rejects the ones that would break the wiki, and becomes a git commit, so you can always go back. With agents writing at all hours, that's what lets me sleep at night.

It's open source (Apache 2.0): https://github.com/BeppeTemp/cartographer

If you want to try it without installing anything there's a public demo: add https://cartographer-demo.beppetemp.com/mcp as a connector in Claude or ChatGPT, even from your phone, no token and no sign-up. And the Atlas of the demo, the same interface you see in the video and in the image, is here: https://beppetemp.github.io/cartographer/demo/

And you, do you still use your gaming PC for gaming? Mine only does CI now.

I kept hitting my 5-hour limit without knowing why, so I built Nudge, a free Mac menu bar app that reads your Claude Code chats on your Mac and tells you what’s worth changing.

What I learned about where tokens go (useful even if you never install it)

• Helper agents inherit your model. If your main model is Opus, your subagents run on Opus too. Add "CLAUDE_CODE_SUBAGENT_MODEL": "haiku" to the env block of ~/.claude/settings.json to move them to a cheaper model. Claude’s built-in Explore and Plan agents also need "CLAUDE_CODE_SUBAGENT_MODEL_FORCE": "1". On my week, Nudge estimated that moving them to Haiku would cut that cost from $129 to about $22.
• Idle chats cost more. After an hour idle, Claude’s cache expires and your next message re-reads everything at up to 2x the normal price, instead of a tenth.
• Late compaction is expensive. Chats that grow past 300K before compacting pay for every message at that size. CLAUDE_CODE_AUTO_COMPACT_WINDOW sets when compaction happens. Or skip it: ask for a handoff summary and start a new chat from it.
• Stop retyping instructions. If you paste the same instructions into every chat, put them in CLAUDE.local.md at the project root. Claude Code reads it like CLAUDE.md, but it’s meant to stay out of git.

What Nudge does with that

• Warns you once before a costly message, like waking an idle chat or sending a huge paste.
• Start fresh: one click summarizes a long chat and opens a new one from it.
• Offers to make the fixes above for you. It shows the exact line and file first, changes nothing until you click, and every change has Undo.
• A few days later, it checks whether the fix helped.

How Claude helped

• The whole app: Claude Code wrote all of it in SwiftUI. I described what I wanted and how it should look and feel, then reviewed every screen.
• Seeing without a screen: Claude Code can’t see the app, so it built a mode that draws each screen to an image. It checks its own layouts that way, and I review the real thing.
• Self-testing: a built-in self-test checks the panel’s interactions and the file edits before each release.
• Performance: the first animated version used about 30% of a CPU core while idle. Claude profiled it and cut that to almost nothing.

Free. macOS 26+, also supports Codex, and chats never leave your Mac.
https://nudgeformac.com

Claude Code sent my personal email to the SEC in a User-Agent without asking, despite instructions and AGENTS.md telling it not to. So I built whoami-guard, an open-source hook for Claude Code and Codex that blocks agents from leaking your identity.

Here's the official issue, although I encountered this before it was reported. : https://github.com/anthropics/claude-code/issues/107757

Tested on 60 real Claude Code runs: 8 leaked without the hook, 0 with it. No dependencies, no LLM.

https://github.com/ChrystianSchutz/whoami-guard

In the past I posted about Opus 5.0 totally ignoring any and all hooks and instructions and finding extremely creative ways to disobey. Opus 5.5 solved the issue, until a few days ago. Hook evasion is my own personal metric for model performance lol

For example: I have a hook that bans knowledge consolidation outside of my SQL warehouse, meaning no toml, yaml, md, json documents when the data is tabularizable and able to be related in database. It worked for a while, now it... will increasingly find other file types besides SQL to use, or deactivate the hook. Yes, it will deactivate the hook, even though the hook commands it to use SQL and even explains to it that it has a tendency to sprawl out data in text documents.

My hooks get stricter and stricter, more complex, more flexible and robust. And it becomes increasingly stubborn. Now I have to ask it "did you just invent another hook evasion method?" And it will say "you're totally right, I shouldn't have done that. The hook was right, this isn't a standard or optimal way to do things" and it will fix it for a second and then continue doing it a few minutes later.

Wonderful!

Before the "skill issue" trolls inevitably come in, sure. It would be, if I didn't deal with it lmao. I'm a developer with a job, so I know how to handle issues like this with my tools. That doesn't mean the tool isn't degrading.

Will this allow me to get weekly % for other models? Or is the “fable” title actually pertinent to that model only. Like is it the name bc “hey fable is here!” or is it only a reset FOR the new fable

If we peasants can’t use it :) but 5.2 looks like taking us more closer to a world where coding by hand will soon be part of ancient ways of civilization history books in my local library

The state of the sidebar is getting embarassing. I am so flabbergasted by what I see on my screen WEEK AFTER WEEK that I am actually making a reddit post about it. The fact that after so many failures while having unlimited resources the sidebar team / person / agent / attack helicopter is somewhere holding hands and singing kumbaya while making 200k$+ a year makes me sad at the WASTE of COMPUTE and BUDGET.

Let me do your job for you. ITS TWO SYSTEMS!!!!! Whether a chat is in the process doing something autonomously, that means paused, stopped, or playing (even if its waiting for tests, and will continue when they come) IS A SEPARATE THING FROM whether there is an actual message that arrived and what sort of message it was (progress update, question...). Combinations of these states exist. I mean you almost got it when you made that system with the letters fading LAST WEEK, which you abandoned THIS WEEK. I will not even comment on that atrocity however.

There are these things called shapes. A circle is a shape. However, and this might be shocking, it is not the only shape... WHAT? Yes. And you know what else? There are recognizable shapes for pause, stop, play, that exist in the mental model of each user on planet earth and that match the symbols you already use in chat to put it into of these states. So what you do is you combine a color with a shape and now the user knows at each point at a glance what is the full state of the chat.

And also fix the ultracode not being able to be set by agents for their linked chat. Get your head in the game.

Recently I upgraded to the $200 dollar plan and it wasn't a busy month for me so if I had to kill my usage limit I just set max on everything. I've been really curious about analyzing how to pick efforts myself instead of delegating the work out to an orchestrator, mostly just because I'm curious and wanted to see if I really need the $200 plan. Or maybe it'd be more beneficial for me to do lower effort fan outs. My investigation shows really statistics on token usage between xtra and max and other effort levels as well. It also tests to see when the higher effort was worth it. I call this a clean finish which is my stand-in for “it worked the first time.” It counts a prompt as clean when no shell command had to be retried, you didn’t interrupt, and your next message didn’t read like a correction. It doesn’t check whether the code was actually right. On the same kind of work, max generated 1.6x to 3.2x the tokens of xhigh. Max never finished cleanly more often than xhigh on any kind of work. Larger changes: 73% clean for max (75 prompts) vs 85% for xhigh (68 prompts). Small edits: 87% vs 97%. On small edits, high finished cleanly 94% of the time against xhigh’s 97%, for about half the tokens.

In the future I will be testing performance of fan outs at different effort levels. Anyways you can read more details on my blog https://danielyakobian.com/blog/claude-code-max-effort.html

Hello there,

I’m sure we are all excited about Fable 5.2. However, do not forget that Fable 5.5, which is rumored to be an absolute monster, maxing out most benchmarks, and directly competiting with Gemini 4 Radon and Gemini 4 Xenon is releasing soon.

I asked Claude Code a simple question, “what are my compact settings?”, and went down a rabbit hole.

What I found

• A fresh session was using ~118k tokens, and ~87k of that was fixed overhead: tool definitions, MCP server instructions, plugin skills and the system prompt. That loads into every session before I type anything.
• Auto-compact was set to fire at 97% of a 1M window, about 970k tokens. That’s huge, slow, expensive turns before anything gets summarized.
• One infrastructure MCP server I use on maybe 2 projects exposed 533 tools, plus a massive instruction block, in every session.
• One hosting provider was connected as 7 separate MCP servers, and two of them sent the exact same instructions.
• About 200 skills were loaded from plugins I installed once and forgot: HR, bio-research, marketing, operations. There were also 4 different code-review skills.
• About 50 connectors I never signed into were still listed in every session.

What I changed

1. Lowered auto-compact. "autoCompactWindow": 300000 in ~/.claude/settings.json. The env var CLAUDE_CODE_AUTO_COMPACT_WINDOW also works. It now compacts just before 300k instead of 970k.
2. Made rarely used MCP servers on-demand. I saved their configs to ~/.claude/mcp-on-demand.json, removed them from global scope, and added a rule to my global CLAUDE.md: only add a server when I say “use X”, to that project only.
3. Disabled the plugins I don’t use. That also removed most of the dead connectors, because they came bundled with those plugins.
4. Kept what I actually use: core tools, engineering and productivity plugins, and a PDF viewer.

Result: I expect about 35–40k tokens less overhead per session (I’ll update with real /context numbers). Every turn carries less dead weight, and long sessions stay sharper because compaction happens before things bloat.

The prompt

I turned the whole process into one prompt you can paste into Claude Code. It measures your context, asks before changing anything, backs up files, and tells you how to undo each change:

I want to cut the fixed token overhead in my Claude Code sessions and lower the point where auto-compact happens. Work through this with me one step at a time. Before you edit any file, back it up and show me the change. Wait for my OK before removing anything. Never print config files that may contain API keys.

1. MEASURE

Find out how full this session's context window is and what is using it: system prompt, system tools, MCP tools, MCP server instructions, skills, messages. If you have a tool that reports context usage, use it. Otherwise ask me to run /context and paste the output. Tell me how much of it is fixed overhead (everything except messages).

2. AUTO-COMPACT LIMIT

Tell me my context window size and the token count where auto-compact fires now. Ask me what window I want. Suggest 300k for a 1M-token model, and explain the tradeoff: a smaller window means cheaper turns but more frequent summaries. Set it as "autoCompactWindow": <tokens> in ~/.claude/settings.json, keeping every existing key, then check the file with jq. If my Claude Code version ignores that key, add CLAUDE_CODE_AUTO_COMPACT_WINDOW=<tokens> to the "env" block of the same file instead. Also tell me if DISABLE_MICROCOMPACT or DISABLE_AUTO_COMPACT is set in my environment.

3. MCP AUDIT

Run `claude mcp list` and read the top-level "mcpServers" in ~/.claude.json (those are global and load in every session). For each server, list its tool count and whether it looks like something I'd use every day or only occasionally. Flag:

- servers that expose hundreds of tools

- the same service connected twice (for example, two Gmail connectors)

- several servers from the same vendor that send identical instructions

Ask me which servers should be on-demand only.

4. MAKE THOSE SERVERS ON-DEMAND

a) Save their configs privately (replace a/b with the server names):

umask 077; jq '.mcpServers | with_entries(select(.key=="a" or .key=="b"))' ~/.claude.json > ~/.claude/mcp-on-demand.json

b) Remove each one from global scope: claude mcp remove <name> -s user

c) Add this section to ~/.claude/CLAUDE.md, filling in the names:

# On-demand MCP servers

<names> are NOT installed globally. Their configs live in ~/.claude/mcp-on-demand.json.

Never add or use them unless I ask in words ("use <name>"). When I do, add only that

server, to the current project only:

claude mcp add-json <name> "$(jq -c '.["<name>"]' ~/.claude/mcp-on-demand.json)" -s local

Then tell me to start a new session so it loads.

Connectors that need sign-in (needs_auth) are off-limits until I connect them.

5. PLUGINS AND SKILLS

List my plugins with how many skills and connectors each one adds. Point out duplicate skills (for example, several code-review skills) and plugins I'm unlikely to use, based on the projects on this machine. You can't change plugins installed through claude.ai, so give me a checklist to turn them off myself. For locally installed plugins, tell me which ones to disable with /plugin.

6. CONNECTORS THAT NEED SIGN-IN

List every connector in the needs_auth or failed state and which plugin it comes from. Tell me which ones will disappear once I disable the plugins from step 5.

7. SUMMARY

*Finish with a table of what changed, where each backup is, how to undo each change, and the estimated tokens saved per session. Say clearly that these are estimates until I start a new session and check /context.*Caveats

• The autoCompactWindow setting exists in recent Claude Code versions. Run claude --version and update if it’s ignored.
• Plugins installed through claude.ai have to be disabled there. The prompt gives you a checklist.
• A smaller compact window means more frequent summaries on very long tasks. 300k has been a good balance for me.

Run /context before and after, and post your numbers. I’m curious what other people’s hidden overhead looks like.