Deleting a file only greys it out locally: nothing is deleted or moved to trash, the grey state is lost on refresh (#22 fix landed, delete is now a no-op)

Start with the delete path in the File Manager frontend, where the optimistic grey-out is applied, and the plugin handler for deleteItem / deleteItems that the request should reach. First confirm in DevTools → Network whether any DELETE or POST request is sent, since that splits frontend from backend. Done means a delete either removes the file and clears the row, or surfaces an error and restores the row; reproduce on a live SSH session to check the liveness-check path.

What happened?

Follow-up on Termix-SSH/Support#192, which you fixed in v1.1.3 — uploads are fine now. Deleting is not: it is a
silent no-op.

Clicking delete marks the item grey in the list, and that is all that ever happens:

- the file is still on the host (verified from a terminal on the same path);
- nothing appears in the File Manager's Trash view;
- refreshing the listing brings the item back to its normal state, so the grey-out was only a
  local/optimistic mark that nothing ever confirmed or rolled back;
- no error toast, no reconnect prompt, nothing.

The decisive detail: `docker logs termix` contains **no trace of the delete at all** during this
container's lifetime — no `Deleting item: …`, no `Item moved to trash`, no
`Failed to move item to trash`, no trash-related error. Before the Termix-SSH/Support#192 fix, a delete at least
reached the plugin and hung there; now it seems not to reach the backend in a usable form (or the
new connection check refuses it and the refusal is dropped somewhere on the way back to the UI).

My hypothesis, purely from the outside: the connection check added for Termix-SSH/Support#192 now decides the file
session is not usable and returns an error for the delete, the request is never issued, and the
optimistic grey-out in the list is neither confirmed nor reverted — because the failure is never
surfaced. Uploads show the outcome, deletes appear to swallow it. If that is right, the fix is two
parts: surface the refusal, and roll the row back when the operation did not happen.

Steps to reproduce

1. Open the File Manager on an SSH host, browse to a folder containing a file you can delete.
   2. Select the file and delete it (also try "Delete permanently").
   3. Observe: the row turns grey, no error is shown.
   4. Check from a terminal on that host: the file is still there.
   5. Refresh the file listing: the row is back to normal, un-greyed.
   6. Open the File Manager's Trash: empty.
   7. docker logs termix at the moment of the click: nothing about the delete.

What did you expect?

Either the file is actually removed (or moved to the plugin's trash) and the row disappears for
good, or the UI says what went wrong and puts the row back immediately. A delete that changes only
local paint, with no server-side effect and no message, is indistinguishable from a broken button —
and it is dangerous in the other direction too: the item looks deleted while it is still on the
host.

Termix version

26.11.0 — File Manager plugin 1.1.3 (log confirms Loaded plugin [email protected]). Upload hang from Termix-SSH/Support#192 is gone in this build; deleting is still broken.

Platform

Web browser

Server install

Docker

Environment

Accessed as http://:9528 over LAN + Tailscale, published straight from Docker with no
reverse proxy in front of it. SQLite as shipped by the image (/app/data/db.sqlite.encrypted), data
on a named volume, single mount. Target hosts are ordinary Linux boxes with SFTP; some sit behind a
jump host that resets idle connections (this is the setup from Termix-SSH/Support#192).
The container has no outbound internet, so plugins never self-update — every plugin fix has to come
through the image tag.
Browser: Edge

Logs

[11:43:21 PM] [INFO] [🧩] Loaded plugin [email protected] [op:plugin_load]

    # then, while clicking delete on a file, nothing:
    $ docker logs termix 2>&1 | grep -icE "Deleting item|moved to trash|Failed to move|deleteItem"
    0

Anything else?

Worth pinning down before the fix, because it decides where the bug lives:

1. Does the browser actually send the request? In DevTools → Network, delete a file and look for
   `DELETE /plugin-api/file-manager/deleteItem` (or `POST /deleteItems`) — status code and response
   body. I can paste that as soon as someone confirms where to look; if there is no request at all,
   this is frontend-side (the optimistic mark firing without the call, or the call gated by the new
   session check).
2. Is the grey-out the "removed" state from the optimistic update that came with the 1.1.2 sidebar
   refresh work, i.e. rows marked gone before the server agrees?
3. Does it reproduce on the Desktop app, and on a host whose session is definitely alive (terminal
   open on the same host, no jump host in between)? That separates "delete is broken" from
   "delete silently refuses when Termix-SSH/Support#192's liveness check trips".

I did not read the plugin source, so Termix-SSH/Termix#2 and Termix-SSH/Termix#3 are guesses from behaviour only — flagging them as
such so nobody chases a wrong lead. Happy to test candidates; the Termix-SSH/Support#192 link above has my full
field evidence for the same session.

Before you submit

• I searched open and closed issues and this is not a duplicate
• I am on the latest version, or I said which version I am on