desktop: audit findings — tracking

[MervinPraison]

A six-lens audit of the desktop app on 27 Aug 2026 produced sixteen defects.
Two were fixes of mine that hadn't worked and are corrected in #4481. These
fourteen are verified, reproduced against the code, and not yet fixed.

Filed individually so they survive the session that found them. Each carries the
reproduction, the file:line, a proposed diff, and the test that should fail
before the fix.

High

• desktop: fetch_url follows redirects, so the approval card authorises one URL and the engine fetches another #4490 — fetch_url follows redirects, so the approval card authorises one URL and the engine fetches another
• desktop: Quitting the app orphans the running fine-tune on macOS and Linux #4491 — Quitting the app orphans the running fine-tune on macOS and Linux
• desktop: Training state is memory-only: a restart loses the live run, and "one GPU runs one job" stops refusing #4492 — Training state is memory-only: a restart loses the live run, and "one GPU runs one job" stops refusing
• desktop: A log-write failure wedges the trainer at "running" forever and blocks every future run #4493 — A log-write failure wedges the trainer at "running" forever and blocks every future run
• desktop: esc() does not escape quotes — a model-authored link injects HTML attributes, and it is persisted #4494 — esc() does not escape quotes: a model-authored link injects HTML attributes, and it is persisted

Medium

• desktop: DELETE /chats/<id> answers {"ok": true} whether or not anything was deleted, and the UI blanks the transcript regardless #4495 — DELETE /chats/<id> answers {"ok": true} whether or not anything was deleted
• desktop: One non-object JSON file in chats/ drops the connection on /chats, /projects and /search #4496 — One non-object JSON file in chats/ drops the connection on /chats, /projects and /search
• desktop: Every settings write reports success unchecked; one failure mode makes Theme a completely dead button #4497 — Every settings write reports success unchecked; one failure mode makes Theme a dead button
• desktop: launch_at_login is persisted before it is attempted, the honest result is discarded, and off macOS it can never work #4498 — launch_at_login is persisted before it is attempted, and off macOS it can never work
• desktop: Windows: the lockfile interpreter can never match, so Decision::Adopt is unreachable — every relaunch kills a healthy engine and takes its fine-tune with it #4499 — Windows: the lockfile interpreter can never match, so Decision::Adopt is unreachable
• desktop: spawn_env — the whole PYTHONPATH/PYTHONHOME defence — has no production caller #4500 — spawn_env, the whole PYTHONPATH/PYTHONHOME defence, has no production caller
• desktop: MCP servers are stored, toggled, persisted, and never launched #4501 — MCP servers are stored, toggled, persisted, and never launched

Low

• desktop: runAction has no error handling — Export, Check for updates and MCP are silently inert when the engine is unreachable #4502 — runAction has no error handling: Export, Check for updates and MCP are silently inert when the engine is unreachable
• desktop: alert() and prompt() survive at three sites, in a page that documents JS dialogs as non-functional here #4503 — alert() and prompt() survive at three sites, in a page that documents JS dialogs as non-functional here

Not from the audit, but open

• The SSH runner behind remote training has three defects: a launch that blocks
  for the whole run, a stop that targets a process group that does not exist,
  and a workdir that creates a literal ~ directory. Remote training will not
  work end to end until these are fixed.
• The engine sends Access-Control-Allow-Origin: * on unauthenticated loopback.
  /settings masks the API key, so a local page cannot steal it — but it can
  read transcripts and drive the app.

The pattern worth noticing

Seven of the bugs found across this whole effort share one shape: a check
confirmed something was attempted rather than that it had an effect. A
button that existed but was never clicked; a run labelled "cancelled" while the
process ran on; a signal sent to a console that did not exist; four release
assets present but two unopenable; a tool tally read after the queue was
drained; a delete hardened at the wrong layer; a fake speaking a status
vocabulary the real runner does not use.

Two of those were in fixes of mine, and both passed their own tests. Mutation
testing — revert the fix, the test must fail — is what caught them.

[praisonai-triage-agent]

Claude finished @MervinPraison's task —— View job • claude/issue-4504-20260827-1352 • [Create PR ➔](https://github.com/MervinPraison/PraisonAI/compare/main...claude/issue-4504-20260827-1352?quick_pull=1&title=Issue%20%234504%3A%20Changes%20from%20Claude&body=This%20PR%20addresses%20issue%20%234504%0A%0AGenerated%20with%20%5BClaude%20Code%5D(https%3A%2F%2Fclaude.ai%2Fcode)

---

Done — desktop audit (#4504)

PR: #4522

Scope decision: #4504 is a tracking issue for 14 separate audit defects. Fixing all 14 in one PR would be unreviewable and violates AGENTS.md's "minimal, focused fix" rule. I implemented the #1-ranked, highest-severity, fully self-contained finding and left the other 13 to their own issues.

Fixed: #4490 — fetch_url follows redirects (approval bypass / loopback SSRF)

The approval card authorises one URL, but urllib.request.urlopen follows 3xx by default — a 302 could send the fetch to any host/port (including this engine on loopback) and return its body to the model under an approval that never named it.

• engine/server.py — fetch via build_opener(_NoRedirect); a redirect now raises a clear "redirect to … was not approved" error the model can act on
• engine/test_chat_stream.py::FetchUrlDoesNotFollowRedirects — two loopback servers (A 302→ B secret); asserts the secret is not returned, plus a guard that a direct fetch still works
• Mutation-verified — reverting the one-line fix makes the test fail (secret leaks); with the fix it passes
• Full engine suite green — 64 passed, 0 regressions

Not done (tracked separately, by design)

The other findings are their own issues: #4491–#4494 (High), #4495–#4501 (Medium), #4502–#4503 (Low), plus the SSH-runner and CORS notes. Several touch src-tauri/ (Rust), which is out of scope for this SDK per the task guidance. Each should get its own minimal PR.

Job run · Branch claude/issue-4504-20260827-1352

[MervinPraison]

All fourteen findings above are now closed, and I checked each fix is actually
present in main rather than trusting the closed label.

Three further defects — from the design review of remote training, not from the
audit — are now filed separately. They were only in a conversation until now:

• praisonai-train: remote stop signals one pid, so a stopped fine-tune keeps running on the GPU #4547 — remote stop signals a single pid, so a stopped fine-tune keeps
  running on the GPU. Same defect as desktop: Quitting the app orphans the running fine-tune on macOS and Linux #4491, which was fixed for local runs only.
• praisonai-train: remote workdir is quoted, so ~ never expands and a directory named '~' is created #4548 — the remote workdir is shlex.quoted, so ~ never expands and a
  directory literally named ~ is created. Affects every run using the default
  workdir.
• praisonai-train: the remote pid file records the wrapper shell, not the trainer #4549 — the pid file records the wrapper shell rather than the trainer, so
  status and stop both watch the wrong process.

Each was reproduced against a real shell, not inferred. Together they mean
remote training does not work end to end yet: a run can be started, but
stopping it does not reliably stop it and its artifacts land in the wrong
directory.

Two things also remain unverified by anyone, and are worth stating plainly:
the Windows and Linux desktop packages have never been installed, and no remote
training run has ever touched a real GPU host.