[zhangt2333]

Thanks for pi-web — I've used it for a long time and really like it; this is the first real problem I've run into.

Problem

Editing a history message reorders the same tools: navigateTreeKeepingToolSelection() re-applies the selection after the navigation restored the branch's loadout, and resolveActiveToolNames() moves every coding tool in front of the carried ones.

before  read,bash,edit,write,todo,ask_user_question,Agent,web_search,…,web_enable,grep,find
after   read,bash,edit,write,todo,ask_user_question,Agent,grep,find,web_search,…,web_enable

Nothing was enabled or disabled: only the order changed, which rewrites the system prompt and drops the cached prefix, so the next request re-bills the whole conversation.

Reproduction

1. New session in Pi Web: send 1, then 2.
2. Edit 2, resend as 2.2.
3. The system prompt is rewritten: the session file gains a new system entry whose <tools> section carries the order above.

[agegr]

Thanks. I reproduced this on main: the new test fails there. With the real SDK and a faux model, navigating back to an earlier leaf moved grep ahead of an extension tool and added a second system entry with a reordered <tools> section. On this branch the order and the prompt stay the same. It only happens when a coding tool sits after a non-coding one, which pi-web never produces itself (here an extension did), so plain setups never see it.

Keeping activeBefore when the set is unchanged but pi's restored order differs is the right call: pi's transcript order can differ from the order the recorded prompt was built in (for example after a Read-only → Default switch), and activeBefore matches the prompt. A different set still goes through the old re-apply, so pins, Chat only, subagents and codemode/tool_search are unchanged. I merged main and added a sentence to docs/agents/tools.md describing the rule.