Found by a six-lens audit of the desktop app on 27 Aug 2026. Every finding was reproduced against the code, not inferred.
Severity: low · audit rank 16 of 16.
Breaks: "Move to project" — the only way to organise conversations — is entirely inert: prompt returns null under WKWebView, if(name===null) return, so right-click issues zero requests and shows nothing at all. And adding an MCP server with a blank name, or one the engine rejects (a server named "fs" already exists), shows nothing anywhere.
Who / likelihood: every macOS user, every time. ui/index.html:900-905 states the platform fact and is the reason askConfirm exists: "A WKWebView under Tauri implements no JS dialog panel, so confirm() returns false immediately without ever showing anything."
Where: ui/index.html:1024 (prompt), :1926 and :1930 (alert).
@@ ui/index.html:1024
- const name=prompt('Move to project (blank to remove):', c.project||'');
- if(name===null) return;
+ // window.prompt shows nothing and returns null in this webview, so
+ // this menu item issued no request at all. askText mirrors askConfirm.
+ const name=await askText('Move to project (blank to remove):', c.project||'');
+ if(name===null) return;
@@ ui/index.html:1926
- if(!name){ alert('A name is required.'); return; }
+ if(!name){ toast('A name is required.'); return; }
@@ ui/index.html:1930
- if(r.error){ alert(r.error); return; }
+ if(r.error){ toast(r.error); return; }askText is askConfirm (:907) with an <input> — ~10 lines, same promise shape.
Test — frontend/tests/buttons.test.mjs. Important: the existing harnesses stub w.prompt = () => 'x' and w.alert = () => {} (buttons.test.mjs:66, settings-effects.test.mjs:77, turn-actions.test.mjs:82, a11y.test.mjs:52, engine-down.test.mjs:48), which is precisely why this survived — the stub models a dialog that works, which this platform does not have. The test must set w.prompt = () => null and w.alert = () => { throw new Error('no dialog panel here'); }, then fire contextmenu on a chat row and assert a POST /project/<id> was issued. Fails today; the current stubs hide it.
Not yet fixed. Filed so it is not lost with the session that found it. The fix and the test above are proposals from the audit — worth re-checking against current main before implementing, since the file has moved since.
Breaks: "Move to project" — the only way to organise conversations — is entirely inert:
promptreturnsnullunder WKWebView,if(name===null) return, so right-click issues zero requests and shows nothing at all. And adding an MCP server with a blank name, or one the engine rejects (a server named "fs" already exists), shows nothing anywhere.Who / likelihood: every macOS user, every time.
ui/index.html:900-905states the platform fact and is the reasonaskConfirmexists: "A WKWebView under Tauri implements no JS dialog panel, soconfirm()returns false immediately without ever showing anything."Where:
ui/index.html:1024(prompt),:1926and:1930(alert).askTextisaskConfirm(:907) with an<input>— ~10 lines, same promise shape.Test —
frontend/tests/buttons.test.mjs. Important: the existing harnesses stubw.prompt = () => 'x'andw.alert = () => {}(buttons.test.mjs:66,settings-effects.test.mjs:77,turn-actions.test.mjs:82,a11y.test.mjs:52,engine-down.test.mjs:48), which is precisely why this survived — the stub models a dialog that works, which this platform does not have. The test must setw.prompt = () => nullandw.alert = () => { throw new Error('no dialog panel here'); }, then firecontextmenuon a chat row and assert aPOST /project/<id>was issued. Fails today; the current stubs hide it.Not yet fixed. Filed so it is not lost with the session that found it. The fix and the test above are proposals from the audit — worth re-checking against current
mainbefore implementing, since the file has moved since.