Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Dropbox panel shows wrong storage info (hardcoded plan quota, e.g. "3.11 GB of 2 GB")
Reported by fabridamicelli · filed Sep 5, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #7597 (R-1629). GitHub close reason: completed.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Description
The Dropbox bar panel displays incorrect storage information. It reports usage as <local folder size> of <hardcoded plan quota>, neither of which reflects the account's real server-side numbers.
shell/plugins/panels/dropbox/status.py derives the quota from a fixed table keyed on the plan name read out of ~/.dropbox/info.json:
PLAN_QUOTAS = {
"basic": 2_000_000_000,
...
}This ignores bonus/referral space, so a Basic account can legitimately have well over 2 GB of quota. Combined with used being a raw local disk scan of ~/Dropbox, the panel routinely shows nonsensical values like "3.11 GB of 2 GB" (used > quota), highlighted in red as if the user were over quota — when in reality the account is fine and syncing reports "Up to date".
This is how it looks on my machine:
<img width="445" height="141" alt="Image" src="https://github.com/user-attachments/assets/d92287e9-2f2f-47c9-9da4-c8f48404891d" />
Steps to reproduce
- Have a Dropbox account whose real quota differs from the base plan quota (e.g. a Basic account with referral/bonus space, holding more than 2 GB).
- Open the Dropbox panel in the Omarchy bar.
- Observe the "Stored" line.
Expected
Usage shown against the account's real quota (including bonus/referral space), matching what the official Dropbox client reports.
Actual
used (local folder scan) shown against a hardcoded plan quota, e.g. "Stored 3.11 GB of 2 GB" in red, incorrectly implying the account is over quota.
<!-- Screenshot showing "Stored 3.11 GB of 2 GB" in red -->
Notes on root cause / fix difficulty
The real quota does not appear to be recoverable locally:
- It lives only in the encrypted
~/.dropbox/instance1/config.dbx. - The daemon's command socket (
~/.dropbox/command_socket) exposesget_dropbox_statusbut no account/quota command.
So a correct fix requires the Dropbox HTTP API (/2/users/get_space_usage), which needs OAuth — and, to work unattended for all users, a Dropbox production app. Flagging that here since it makes this more than a trivial patch.
View raw text
## Description
The Dropbox bar panel displays **incorrect storage information**. It reports usage as `<local folder size> of <hardcoded plan quota>`, neither of which reflects the account's real server-side numbers.
`shell/plugins/panels/dropbox/status.py` derives the quota from a fixed table keyed on the plan name read out of `~/.dropbox/info.json`:
```python
PLAN_QUOTAS = {
"basic": 2_000_000_000,
...
}
```
This ignores **bonus/referral space**, so a Basic account can legitimately have well over 2 GB of quota. Combined with `used` being a raw local disk scan of `~/Dropbox`, the panel routinely shows nonsensical values like **"3.11 GB of 2 GB"** (used > quota), highlighted in red as if the user were over quota — when in reality the account is fine and syncing reports "Up to date".
This is how it looks on my machine:
<img width="445" height="141" alt="Image" src="https://github.com/user-attachments/assets/d92287e9-2f2f-47c9-9da4-c8f48404891d" />
## Steps to reproduce
1. Have a Dropbox account whose real quota differs from the base plan quota (e.g. a Basic account with referral/bonus space, holding more than 2 GB).
2. Open the Dropbox panel in the Omarchy bar.
3. Observe the "Stored" line.
## Expected
Usage shown against the account's real quota (including bonus/referral space), matching what the official Dropbox client reports.
## Actual
`used` (local folder scan) shown against a hardcoded plan quota, e.g. **"Stored 3.11 GB of 2 GB"** in red, incorrectly implying the account is over quota.
<!-- Screenshot showing "Stored 3.11 GB of 2 GB" in red -->
## Notes on root cause / fix difficulty
The real quota does not appear to be recoverable locally:
- It lives only in the encrypted `~/.dropbox/instance1/config.dbx`.
- The daemon's command socket (`~/.dropbox/command_socket`) exposes `get_dropbox_status` but no account/quota command.
So a correct fix requires the Dropbox HTTP API (`/2/users/get_space_usage`), which needs OAuth — and, to work unattended for all users, a Dropbox production app. Flagging that here since it makes this more than a trivial patch.
- d92287e9-2f2f-47c9-9da4-c8f48404891d
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.
No decision has been recorded yet.