fix(wake-config): stop dropping per-peer baseInstructions - #98
Open
alexanderyswork wants to merge 2 commits into
Open
fix(wake-config): stop dropping per-peer baseInstructions#98alexanderyswork wants to merge 2 commits into
alexanderyswork wants to merge 2 commits into
Conversation
…ip resume A thread seeded inside the wake call has no rollout file until its first turn, so thread/resume always failed on it with 'no rollout found'. That failure left threadPath null, which silently disabled the session-log completion fallback — the only path that actually completes a turn on Codex CLI 0.145. Result: Codex answered, the answer sat in the session JSONL, and the daemon timed out without relaying it. - buildThreadStartParams now carries peer cwd/model, so a seeded thread no longer starts in / with no project instructions or workspace roots - the thread/start response path is kept as threadPath (it was discarded) - a freshly seeded thread is no longer resumed; re-seed shares one code path - normalizeWakeConfig preserves the resume flag, which it dropped entirely, making the injector's resume opt-out unreachable from real config Tests cover the gap that broke in production: relayFinalToMurmur with no threadId configured. Refs alexfrmn#96 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The channel binding resolver falls back to peer.baseInstructions when no baseInstructionsResolver is injected — which is exactly how murmur-daemon wires it. normalizeWakeConfig dropped the field, so per-peer role instructions were impossible to set from a real config. That left personaId as the only lever, and Codex CLI 0.145 rejects anything outside its own enum: codex-app-server-error:Invalid request: unknown variant `critic`, expected one of `none`, `friendly`, `pragmatic` So channel roles could not be expressed at all: free-form personas are refused by the server and instructions never reached it. With this change a peer can carry role instructions and the binding logs hasBaseInstructions: true. Refs alexfrmn#96 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Small companion to #97, found while trying to give a Codex peer a channel role.
Problem
createChannelThreadStartBindingResolverfalls back topeer.baseInstructionswhen nobaseInstructionsResolveris injected — which is exactly howmurmur-daemon.mjswires it. ButnormalizeWakeConfigdropped the field, so per-peer role instructions could not be set from a real config at all.That leaves
personaIdas the only lever for a role, and Codex CLI 0.145 refuses free-form personas:Net effect: channel roles were unusable end to end — the server rejects arbitrary personas, and the instructions that would express the role never survived config normalization.
Change
normalizeWakeConfigpreserves a non-empty stringbaseInstructions, mirroring theresumefix in #97.Verified live: before, the daemon logged
hasBaseInstructions: falsefor a channel member; after,hasBaseInstructions: true, and the member'smodelfrom the roster is applied.Test
normalizeWakeConfig preserves per-peer baseInstructions— red before the change.node --test tests/codex-app-server-wake.test.mjs→ 20/20.Note for the docs
It may be worth documenting that
personaIdin a channel roster cannot be a free-form label for Codex targets: the app-server validates it againstnone|friendly|pragmaticand fails the whole turn otherwise. Role wording belongs inbaseInstructions.🤖 Generated with Claude Code