feat(launch): make Headroom opt-in and wire RTK when the entry file lacks the block - #23
Merged
Merged
Conversation
…acks the block What a bare `scc launch` does, and does not, is now settled by one question: does this leave anything behind after the session ends? Headroom's `wrap` does — it registers MCP servers into the agent's own config, and those registrations outlive the session that made them, which is why Headroom ships `unwrap` at all. What it buys is one session of compression, so it moves behind `--headroom`; without the flag scc does not even look for the binary, and the report omits the field entirely rather than saying "skipped". Any `--headroom-*` flag implies `--headroom`, because accepting a flag and then ignoring it is how somebody spends a session believing they configured something. With the flag, the internal defaults are unchanged: `--headroom-mcp none` and `--no-context-tool`. RTK goes the other way, and the trigger is the block rather than the binary: it runs when an entry file carries no RTK block and does nothing at all when they all do. That bound is what lets it be the default — it fires once per workspace rather than once per session, so a wired workspace pays no cargo prompt and no edit at the top of every session. The write is the point: an agent that never read the block never types the prefix, so installing the binary and leaving the file alone would buy nothing. It splices with keep, so a block already there is left exactly as it is even when scc ships a different one; replacing somebody's block is a real trade-off and `scc rtk` is where it is made deliberately. Two smaller consequences. A plan-only run now passes check through to applyRTK, which closes a real hole: `--rtk --dry-run` used to splice the entry file, the one flag nobody expects to change anything doing exactly that. And a workspace whose block is present while the binary is not gets one warning and no action — the file tells the agent to use a binary this machine lacks, but that is a PATH problem on the user's side rather than something to fix mid-launch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018CAEQdLsrScdfaa1ut2H7g
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.
Settles what a bare
scc launchdoes by one question: does this leave anything behind after the session ends?Headroom moves behind
--headroom.wrapregisters MCP servers into the agent's own config and those registrations outlive the session — which is why Headroom shipsunwrap. What it buys is one session of compression, so it is opt-in; without the flag scc does not even look for the binary and the report omits the field rather than saying "skipped". Any--headroom-*flag implies--headroom, because accepting a flag and then ignoring it is how somebody spends a session believing they configured something. With the flag, the internal defaults are unchanged (--headroom-mcp none,--no-context-tool).RTK goes the other way, bounded by the block, not the binary. Preflight runs when an entry file carries no RTK block and does nothing at all when they all do — so it fires once per workspace rather than once per session, and a wired workspace pays no cargo prompt and no edit at the top of every session. The write is the point: an agent that never read the block never types the prefix. It splices with
keep, so a block already there is left exactly as it is; replacing somebody's block is a real trade-off andscc rtkis where it is made deliberately.Two smaller consequences:
checkthrough toapplyRTK, closing a real hole —--rtk --dry-runused to splice the entry file, the one flag nobody expects to change anything doing exactly that.🤖 Generated with Claude Code
https://claude.ai/code/session_018CAEQdLsrScdfaa1ut2H7g