Found during the round-2 review of #222 and handed off rather than fixed there: it is pre-existing on main from the keep-alive work (#196 / #212), unrelated to that branch's change, so it gets its own issue and branch per the repo rule.
The misreport
start-proxy.sh passes --config whenever a keep-alive config exists for the port (scripts/start-proxy.sh:264-268):
CONFIG_ARGS=()
KEEPALIVE_CFG="${STATE}/keepalive-${PORT}.yaml"
if [ -f "$KEEPALIVE_CFG" ]; then
CONFIG_ARGS=(--config "$KEEPALIVE_CFG")
fi
But the success note still reports the preset from the plugin option (:309 and :314):
note "proxy up on 127.0.0.1:${PORT} (preset ${PRESET}, idle-exit ${IDLE_EXIT})."
where PRESET="${CLAUDE_PLUGIN_OPTION_PRESET:-cache}" (:31).
Since --config replaces --preset entirely — loadConfig returns config.Load(path) and never consults preset once --config is set — the proxy actually runs whatever preset: the keep-alive file recorded. The reported value and the effective value are independent, and they diverge the moment somebody changes the plugin option after enabling keep-alive:
plugin option preset=house, keepalive-8787.yaml written earlier with preset: cache
-> proxy runs `cache`
-> note says "(preset house, …)"
Nothing errors. It is a confident report of a value that is not in effect — the same species as #221, which is how it was spotted.
Suggested fix
Report the preset that is actually in effect: when CONFIG_ARGS is non-empty, read the preset: line out of $KEEPALIVE_CFG for the note (and say the config file is in play), rather than printing $PRESET. Worth a test in the same shape as TestStartProxyPicksUpAKeepaliveConfig, asserting the note names the config's preset and not the option's when the two differ.
Note this interacts with #223: once the discovery instructions are per-option, PRESET may legitimately be the plugin.json default rather than anything the user set, which makes an accurate note more useful, not less.
Found during the round-2 review of #222 and handed off rather than fixed there: it is pre-existing on
mainfrom the keep-alive work (#196 / #212), unrelated to that branch's change, so it gets its own issue and branch per the repo rule.The misreport
start-proxy.shpasses--configwhenever a keep-alive config exists for the port (scripts/start-proxy.sh:264-268):But the success note still reports the preset from the plugin option (
:309and:314):note "proxy up on 127.0.0.1:${PORT} (preset ${PRESET}, idle-exit ${IDLE_EXIT})."where
PRESET="${CLAUDE_PLUGIN_OPTION_PRESET:-cache}"(:31).Since
--configreplaces--presetentirely —loadConfigreturnsconfig.Load(path)and never consultspresetonce--configis set — the proxy actually runs whateverpreset:the keep-alive file recorded. The reported value and the effective value are independent, and they diverge the moment somebody changes the plugin option after enabling keep-alive:Nothing errors. It is a confident report of a value that is not in effect — the same species as #221, which is how it was spotted.
Suggested fix
Report the preset that is actually in effect: when
CONFIG_ARGSis non-empty, read thepreset:line out of$KEEPALIVE_CFGfor the note (and say the config file is in play), rather than printing$PRESET. Worth a test in the same shape asTestStartProxyPicksUpAKeepaliveConfig, asserting the note names the config's preset and not the option's when the two differ.Note this interacts with #223: once the discovery instructions are per-option,
PRESETmay legitimately be theplugin.jsondefault rather than anything the user set, which makes an accurate note more useful, not less.