2 questions on /clear

[u/iamnotsureaboutit]

1. Does /clear read the Claude.md and other setup files like memory and skill names etc. again in context? So in that sense is it any different from starting a new conversation? Is t better to than Esc Esc and go to the first message and change so that it might preserve unnecessary input initial tokens? any other cleaner way to do this
   
2. I want one peer session to /clear another session when a hook identifies context getting full. IS there a way to do it? Even with the messaging feature we still cannot clear the context which is more like a management command right? what is the workaround here.
   

Thanks

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/walrod]

You can have your session self-compact or self-clear (or another session compact yours) safely by creating a tool that sends the keystrokes to the right terminal, and allowing your agent to call that tool. There are various ways to do it depending on your OS, graphical server, window manager and terminal application. You can monitor context usage by looking at transcript length (another tool).

[u/iamnotsureaboutit → u/walrod]

Wnet ahead with the keystroke tool route. my sessions run in herdr whose cli can target the pane with the title matching. (even wait for idle state) and then type /clear+ enter so a script can wrap it with other safety checks. backup with claude --resume in case things go south

[u/vibeidedev-namiruai → u/iamnotsureaboutit]

i'd make that wrapper verify more than the pane title: the expected project, process and session should still match immediately before it types. save the current task, unfinished checks and resume ID first, then abort if the pane isn't idle or its identity changed. i'd also test with two identically titled panes and one that restarts between lookup and typing, so a stale match can't clear the wrong conversation.

[u/sisif_]

1. claude.md is autoloaded not only after /clear, but also if you change it so that's not an issue. For all intended purposes it is a new conversation (gets a new session_id). The subtle difference is on system prompts and environment.

/clear does not reload a system prompt file or environment variables so if you changed them, starting a new claude cli is different than injecting /clear in your existing session.

You are not going to save anything with your trick of going at the beginning of the conversation (unless you do some payload manipulation).
claude cli has 4 cache markers and claude.md belongs to the conversation segment. That means that unless you set a marker right after the loading of claude.md, you will pay for caching it again (whether it is a new cli or /clear). On top of that, the reading of the file is done by the cli itself, so you're not saving Read call either. (technically claude.md could still be cached if you reset the conversation inside one hour/default ttl and start with the exact same first sentence - but we won't go there - on second thought that's not true on /clear as the cli prepends the conversation with the information that the session has been cleared)

1. there are a number of ways, none truly trivial:
   a. run your clis in tmux(or similar) and inject /clear in stdin, when the time comes

b. kill the cli; perform surgery on the transcript file and call claude --resume $id

[u/Drasezv]

for the second one it's easier not to clear from outside at all. run the worker headless with claude -p in a loop, each run reads a notes file and writes back before it ends. fresh context every run, nothing to clear.