Repository navigation
fix: never replay the launcher's own Claude channel flags on resume - #31
Merged
Merged
Conversation
After a power outage, one Claude session failed to wake twice with "The provider process did not initialize". Its stored launch flags still carried --dangerously-load-development-channels server:slack-bridge, recorded under the pre-September launcher. displayFlagsFor() strips only --resume and --continue, so resumeArgsFor() replayed that flag. Since the launcher adds it again, Claude listed the channel twice: Channels: server:slack-bridge, server:slack-bridge The consent helper confirms only a list that is exactly SAB's channel, so the development-channel prompt waited for a human and SessionStart never came. While the launcher used --channels, the old helper's blind Enter had hidden the stale flag. - displayFlagsFor() now drops the launcher-owned --mcp-config, --channels and --dangerously-load-development-channels (with their values or `=` forms) from stored Claude flags. Resume arguments and flag display therefore never repeat them. - The consent helper also accepts a channel list made only of server:slack-bridge. Any other entry still waits for a human. Only that one session had such stored flags. Restoring either behaviour turns the new tests red. Full suite: 593 pass. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011Xs8AVBVrTGfpzUMiCQp2R
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
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
After a power outage, a Claude session failed to wake twice with "The provider process did not initialize". This was a regression from #30.
Root cause
--dangerously-load-development-channels server:slack-bridge, recorded under the pre-September launcher.displayFlagsFor()strips only--resumeand--continue, soresumeArgsFor()replayed that flag.Channels: server:slack-bridge, server:slack-bridge(verified on 2.1.296).--channels, the old blind-Enter helper had hidden the stale flag.Fix
displayFlagsFor()drops the launcher-owned--mcp-config,--channelsand--dangerously-load-development-channels(with their values or=forms) from stored Claude flags. Resume arguments and flag display never repeat them.claude-consent.shalso accepts a list made only ofserver:slack-bridgeentries. Any other entry still waits for a human.Tests
Claude resume never replays the launcher's own channel and MCP flags, built from the exact stored flags of the failing session. Codex keeps its own flags.npm test: 593 pass.check,audit,node --checkandshellcheckall pass.Deployment notes
🤖 Generated with Claude Code
https://claude.ai/code/session_011Xs8AVBVrTGfpzUMiCQp2R