notifications/tools/list_changed doesnt reload codex? codex bug?

docs/f/mre.py

@@ -36,7 +36,9 @@ async def downstream_message_handler(message: object) -> None:
         downstream_seen.append(message.root.method)
 
 
-upstream_transport = FastMCPTransport(server) # any transport will do, tried python stdio, and fastmcp, both reproduce.
+upstream_transport = FastMCPTransport(
+    server
+)  # any transport will do, tried python stdio, and fastmcp, both reproduce.
 
 
 async def prog() -> None:
@@ -60,7 +62,9 @@ async def prog() -> None:
         "notifications/message",
     ]
     assert upstream_seen == seen
-    assert downstream_seen == seen, "bug here: notifications should be forwarded by the proxy"
+    assert downstream_seen == seen, (
+        "bug here: notifications should be forwarded by the proxy"
+    )
 
 
 asyncio.run(prog())

docs/mcp_protocol_proxy_inventory.md

@@ -93,6 +93,14 @@ Tool simulate-research-query requires task augmentation (taskSupport: 'required'
 - Sampling was not visible as a direct listed tool in the current Everything
   server inventory.
 
+- Dynamic tool-list adoption is harness-dependent. On 2026-05-17, after
+  enabling `playwright.default` and reloading `wf-mcp`, the server-side admin
+  inventory showed the new proxy tools immediately. After restarting Codex, the
+  UI could show `playwright.default.browser_navigate`, but the current model turn
+  still did not receive a callable tool binding for it. That means a host can
+  observe an updated `tools/list` without rebuilding the tool schema supplied to
+  an already-running model interaction.
+
 ### Current Classification
 
 - Proxy tool projection: healthy for ordinary tools.
@@ -109,6 +117,9 @@ Tool simulate-research-query requires task augmentation (taskSupport: 'required'
   MCP task support is implemented.
 - Notifications/logging/subscriptions: unverified; current client did not show
   forwarded notifications.
+- Dynamic tool-list adoption: server-side updates work, but LLM harnesses may
+  keep a stale or separately-materialized callable tool schema even after a UI
+  refresh or reconnect.
 
 ## Next Test Targets
 

docs/wf_mcp_proxy_reality_and_roadmap.md

@@ -99,6 +99,36 @@ classified as a proxy bug.
 Task-required tools are discoverable but not usable through our current surface.
 This is a real protocol-support gap, not an ordinary tool-call issue.
 
+### 5. LLM harnesses may not adopt dynamic tool changes reliably
+
+`wf-mcp` can expose new tools after reload, but that does not guarantee an agent
+harness rebuilds the callable tool schema for the model turn that is already in
+flight.
+
+Observed on 2026-05-17 with Codex:
+
+- `playwright.default` was enabled
+- `wf.admin.reload_config` remounted it successfully
+- `wf.admin.list_proxy_tools` showed the new tools
+- after reconnect, the Codex UI showed `playwright.default.browser_navigate`
+- the model turn still did not receive a callable binding for that new tool
+
+This is a common Codex / Claude Code / general LLM harness class of problem, not
+just a proxy-server problem. The host may refresh `tools/list` for display or
+inspection while model invocation still uses a previously materialized tool
+schema.
+
+Design consequence: do not make core workflows depend on newly registered MCP
+tools becoming callable immediately. Prefer stable control tools plus explicit
+inspection/call paths when the client must work reliably across harnesses.
+
+When the exposed tool catalog grows large or changes often, FastMCP's search
+transform is a good mitigation: keep a stable pinned control/workflow spine
+visible, and use `search_tools` plus its synthetic `call_tool` for the changing
+rest of the catalog. Do not confuse that synthetic raw-tool caller with a
+future workflow-capability test tool; testing a normalized `NodeSpec` contract
+is a separate operation and should also remain pinned once it exists.
+
 ## What Is Probably Not Worth Owning Yet
 
 Do **not** rush to implement a custom full protocol relay for:

docs/workflow_artifacts.md

@@ -47,9 +47,11 @@ wf.workflow.run_deployment
 ```
 
 This is important because MCP clients may not reliably refresh `tools/list` when
-new workflow artifacts are saved. A stable `run_deployment` tool lets an LLM
-test saved workflows immediately without requiring dynamic tool registration or
-tool-list notifications to work perfectly.
+new workflow artifacts are saved. More specifically, LLM harnesses may refresh
+or display a changed tool list without rebuilding the callable tool schema used
+for the current model turn. A stable `run_deployment` tool lets an LLM test saved
+workflows immediately without requiring dynamic tool registration or tool-list
+notifications to work perfectly.
 
 This control surface should not fork between backend service layers. The public
 server now has one exposure style, but internally it still combines: