Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-272GitHub issuePublicDecided· Out of scope

Dropbox widget's 60s status poll rotates the link nonce, breaking its own Log in button

Reported by eyadsibai · filed Sep 20, 2026 · open at source

Decided: Out of scope — decided by agents · verified 3 days ago.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaOutside the audited area· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

Dropbox widget's 60s status poll rotates the link nonce, breaking its own Log in buttonrevision 1 · captured 2026-09-28 21:23 UTC via poll

What happened

The Dropbox widget polls dropbox-cli status on a 60-second timer. Every call to
dropbox-cli status mints a brand-new cli_link_nonce, which invalidates the
previous one. While the machine is unlinked, the widget therefore rotates the pending
link URL once a minute — including the URL its own Log in button just opened.

Signing in to Dropbox in a browser (account picker, password, 2FA) reliably takes longer
than 60s, so by the time you confirm, the nonce you were handed is stale. Dropbox's web
page still renders a success state, so it looks like the device linked. It didn't, and
the widget stays greyed out with no error shown.

I lost two days to this before working out what was happening.

Verification

Three consecutive calls, nothing else touching the daemon:

$ dropbox-cli status | grep -o 'nonce=[a-f0-9]*'
nonce=259f2290eefb5ba4000dc793457fd41d
$ dropbox-cli status | grep -o 'nonce=[a-f0-9]*'
nonce=91a12b43b9b2a6eba37e387021770d12
$ dropbox-cli status | grep -o 'nonce=[a-f0-9]*'
nonce=619f9a4d9e65a0942b9dc8fef7f4bd3f

dropbox-cli status reaches grab_link_url_if_necessary() → dc.needs_link(), and the
daemon returns a fresh link_url each time.

Code path

  • shell/plugins/panels/dropbox/Service.qml:161-167 — refreshTimer, repeat: true,

triggeredOnStart: true, interval: refreshIntervalSec * 1000
- shell/plugins/panels/dropbox/Service.qml:34 — refreshIntervalSec defaults to 60
- shell/plugins/panels/dropbox/Service.qml:64 — statusProcess.command = ["python3", helperPath, "25"]
- shell/plugins/panels/dropbox/status.py:102 — command_output([dropbox_cli, "status"])

Service.qml:172-186 (startupRamp) also polls every 2s for up to 30s, which compounds
this immediately after shell start.

Steps to reproduce

  1. Have dropbox, dropbox-cli installed and the daemon running but not linked
  2. Add omarchy.dropbox to the bar
  3. Click the widget → Log in; it opens a cli_link_nonce URL
  4. Spend >60s completing sign-in in the browser
  5. The web page reports success; dropbox-cli status still says

Waiting to be linked to a Dropbox account... and the widget stays grey

Expected

The login flow should hold a stable nonce until it succeeds or is cancelled.

Suggested fixes

Any one of these would do it:

  1. Suspend the refresh timer while a login is in flight. login() (Service.qml:99)

could stop refreshTimer and restart it on success or after a timeout. Smallest change.
2. Don't call `dropbox-cli status` when unauthenticated. status.py can detect the
unlinked state from the absence of ~/.dropbox/info.json without asking the daemon,
which is what rotates the nonce.
3. Cache the nonce. Parse the URL once, reuse it, and only re-mint on explicit user
action.

Workaround

Set refreshIntervalSec to its 3600 maximum on the omarchy.dropbox entry in
~/.config/omarchy/shell.json (hot-reloads), complete the link, then revert:

{ "id": "omarchy.dropbox", "refreshIntervalSec": 3600 }

System

  • Omarchy: omarchy-dev 4.0.0.r1832.g23dab9e-1
  • Kernel: 7.2.6-arch2-1, Hyprland 0.56.2
  • CPU/GPU: AMD Ryzen 9 8945HS w/ Radeon 780M
  • dropbox 270.4.3312-1, dropbox-cli 2026.05.06-1
View raw text
## What happened

The Dropbox widget polls `dropbox-cli status` on a 60-second timer. Every call to
`dropbox-cli status` mints a **brand-new** `cli_link_nonce`, which invalidates the
previous one. While the machine is unlinked, the widget therefore rotates the pending
link URL once a minute — including the URL its own **Log in** button just opened.

Signing in to Dropbox in a browser (account picker, password, 2FA) reliably takes longer
than 60s, so by the time you confirm, the nonce you were handed is stale. Dropbox's web
page still renders a success state, so it looks like the device linked. It didn't, and
the widget stays greyed out with no error shown.

I lost two days to this before working out what was happening.

## Verification

Three consecutive calls, nothing else touching the daemon:

```
$ dropbox-cli status | grep -o 'nonce=[a-f0-9]*'
nonce=259f2290eefb5ba4000dc793457fd41d
$ dropbox-cli status | grep -o 'nonce=[a-f0-9]*'
nonce=91a12b43b9b2a6eba37e387021770d12
$ dropbox-cli status | grep -o 'nonce=[a-f0-9]*'
nonce=619f9a4d9e65a0942b9dc8fef7f4bd3f
```

`dropbox-cli status` reaches `grab_link_url_if_necessary()` → `dc.needs_link()`, and the
daemon returns a fresh `link_url` each time.

## Code path

- `shell/plugins/panels/dropbox/Service.qml:161-167` — `refreshTimer`, `repeat: true`,
  `triggeredOnStart: true`, `interval: refreshIntervalSec * 1000`
- `shell/plugins/panels/dropbox/Service.qml:34` — `refreshIntervalSec` defaults to **60**
- `shell/plugins/panels/dropbox/Service.qml:64` — `statusProcess.command = ["python3", helperPath, "25"]`
- `shell/plugins/panels/dropbox/status.py:102` — `command_output([dropbox_cli, "status"])`

`Service.qml:172-186` (`startupRamp`) also polls every 2s for up to 30s, which compounds
this immediately after shell start.

## Steps to reproduce

1. Have `dropbox`, `dropbox-cli` installed and the daemon running but **not** linked
2. Add `omarchy.dropbox` to the bar
3. Click the widget → **Log in**; it opens a `cli_link_nonce` URL
4. Spend >60s completing sign-in in the browser
5. The web page reports success; `dropbox-cli status` still says
   `Waiting to be linked to a Dropbox account...` and the widget stays grey

## Expected

The login flow should hold a stable nonce until it succeeds or is cancelled.

## Suggested fixes

Any one of these would do it:

1. **Suspend the refresh timer while a login is in flight.** `login()` (`Service.qml:99`)
   could stop `refreshTimer` and restart it on success or after a timeout. Smallest change.
2. **Don't call `dropbox-cli status` when unauthenticated.** `status.py` can detect the
   unlinked state from the absence of `~/.dropbox/info.json` without asking the daemon,
   which is what rotates the nonce.
3. **Cache the nonce.** Parse the URL once, reuse it, and only re-mint on explicit user
   action.

## Workaround

Set `refreshIntervalSec` to its 3600 maximum on the `omarchy.dropbox` entry in
`~/.config/omarchy/shell.json` (hot-reloads), complete the link, then revert:

```json
{ "id": "omarchy.dropbox", "refreshIntervalSec": 3600 }
```

## System

- Omarchy: `omarchy-dev 4.0.0.r1832.g23dab9e-1`
- Kernel: 7.2.6-arch2-1, Hyprland 0.56.2
- CPU/GPU: AMD Ryzen 9 8945HS w/ Radeon 780M
- `dropbox 270.4.3312-1`, `dropbox-cli 2026.05.06-1`

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

  • Out of scopeDecided by agents · verified · 2026-10-09 16:41 UTC