Queue appears blank / items don’t appear

Symptom: The receiver queue is empty even though the sender has items queued.

Cause: This is usually a stale page or SSE connection issue.

Resolution:

  1. Refresh the receiver browser tab (F5 or Cmd+R)
  2. Check the connection status badge — if it shows Reconnecting or Disconnected, wait for it to turn green
  3. If the badge stays disconnected, verify the sender is still running
  4. If items were queued before the receiver connected, they should appear after the initial queue load on connect

“Invalid Date” or garbled text in queue

Symptom: Dates or text in the queue display as “Invalid Date” or appear garbled.

Cause: A browser caching or rendering issue, or a mismatch between an old receiver session and a new sender.

Resolution:

  1. Hard refresh the page: Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (macOS)
  2. If the issue persists, clear browser cache for localhost
  3. Ensure the receiver URL and secret match the current sender session

401 Unauthorized when opening the sender UI

Symptom: Opening http://localhost:5000 in the browser shows a plain 401 Unauthorized response — the UI does not load.

Cause: The sender web UI is protected by a one-time access token. Direct navigation to http://localhost:5000 without the token (or without the ui_token cookie from a previous authenticated visit) is intentionally rejected.

Resolution:

  1. Use the URL the sender printed at startup. Look for the Web UI line in the terminal — it includes the ?token= parameter:

      Web UI : http://localhost:5000/?token=a1b2c3d4... (opening in browser...)

    Copy that full URL (including ?token=...) into your browser.

  2. Let the tool open the browser for you. By default the sender opens your default browser automatically to the correct URL. If you closed the tab, copy the token URL from the terminal instead of navigating to localhost:5000 directly.

  3. If you have already visited the token URL once, your browser stores the ui_token HttpOnly cookie. Simply navigate to http://localhost:5000 — the cookie will authenticate you. The 401 only occurs when the cookie is absent (e.g. a different browser, an incognito window, or after clearing cookies).

  4. If you restarted the sender, a new token is generated on each start. The old cookie is no longer valid — use the new ?token= URL from the latest startup output.

ℹ️ Info: This protection prevents any local process, browser extension, or malware from accessing the sender UI and reading the encryption secret embedded in the page HTML. See Security Features — Sender Web UI Token for full details.

404 on sender root / UI does not load

Symptom: Opening http://localhost:5000 shows a 404 or “connection refused”.

Cause: The sender is not running, or is running on a different port.

Resolution:

  1. Check if the sender process is still running in your terminal
  2. If it exited unexpectedly, restart it: cloud-share-sender
  3. If you started with a custom port, use that port: http://localhost:<port>

File or text size exceeded

Symptom: Upload fails with:

  Error: File exceeds maximum size of 100 MB

or

  Error: Text exceeds maximum size of 10 MB

Cause: The content is larger than the allowed limit.

TypeLimit
Text10 MB
File100 MB
Zip bundle100 MB

Resolution:

  • For text: split into smaller chunks, or save as a file and use file transfer
  • For files: compress the file first, split it with split (Linux/macOS) or 7-Zip (Windows), or use a different transfer mechanism for very large files
  • For zips: remove some files from the bundle and send in multiple transfers

Zip password forgotten

Symptom: The receiver downloaded a zip bundle but cannot open it — the password is not known.

Cause: The zip password was set by the sender but not communicated to the receiver, or was forgotten.

Resolution:

The zip password cannot be recovered — it is not stored anywhere in the cloud-share system. The sender must:

  1. Re-create the zip bundle with a new (known) password
  2. Queue the new bundle
  3. Communicate the new password to the receiver through a secure channel

Getting more diagnostic information

For any issue not covered here, run with verbose logging to see detailed output:

  # Sender
cloud-share-sender --log verbose

# Receiver
cloud-share-receiver --log verbose

Verbose logging shows:

  • DevTunnels CLI output and tunnel creation steps
  • All incoming HTTP requests and responses
  • SSE connection events and reconnection attempts
  • Encryption and hash computation steps (without revealing plaintext)