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.
Terminal typing lag after opening a new terminal — clears only after a genuine idle pause, tied to mise/starship/zoxide/ble.sh prompt stack
Reported by djoleluk · filed Sep 24, 2026Closed upstream on 2026-09-24 by its own reporter djoleluk, as not planned. Closed by its own reporter — not by itself evidence of a fix.
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
Environment
- Omarchy (Hyprland), foot 1.28.0
- ble.sh: blesh-git 0.4.0_devel4.r2350.d81fd54f-1 (AUR)
- Default bash rc chain (mise activate, starship init, zoxide init, bash-completion, ble.sh)
Symptom
Typing immediately after opening a new terminal is laggy/stuttery (~100-200ms
per keystroke) for the first several commands. The lag does NOT go away just
by continuing to type/run commands (tested across 5+ sequential commands).
It only clears after a genuine, uninterrupted idle pause of a few seconds
with zero input — after that, typing is instant (~10-30ms) for the rest of
the session.
What I ruled out (instrumented reproduction, not guesswork)
- bash history file size — cleared ~/.bash_history entirely, identical lag.
- ble.sh's
term_modifyOtherKeys_externalbleopt — changed live, no effect. - ble.sh's async history-array-construction / multiline-history-fixup idle
tasks — forced both synchronous via a blehook ATTACH!=... hook, no
improvement.
- foot itself — reproduced identically in a bare synthetic pty
(Python pty.openpty() + bash -i, no terminal emulator involved at all).
What the lag actually corresponds to
Traced via /proc/<pid>/wchan + child-process sampling: after every single
command, Omarchy's default PROMPT_COMMAND chain spawns mise (hook-env),starship (2-4x per prompt, including the right-prompt call), zoxide,
plus stty calls ble.sh makes around external command execution. This
whole burst takes ~100-200ms combined in the first few commands after
opening a terminal, and drops to ~10-30ms only after a real idle gap.
Notably, the lag disappears entirely when the shell runs under strace,
suggesting a timing-sensitive race rather than a fixed cost — possibly
CPU governor / cgroup CPU-quota related rather than anything in
mise/starship/zoxide/ble.sh's own code.
Possibly related
- #4087 (periodic stalls, delayed keystrokes, CPU governor toggling didn't help)
- #3685 (mise hook overwritten by starship/zoxide — same rc chain, different bug)
- #1684 (slow terminal/Nautilus launches on laptop, undiagnosed)
Happy to share the pty reproduction script if useful.
View raw text
### Environment - Omarchy (Hyprland), foot 1.28.0 - ble.sh: blesh-git 0.4.0_devel4.r2350.d81fd54f-1 (AUR) - Default bash rc chain (mise activate, starship init, zoxide init, bash-completion, ble.sh) ### Symptom Typing immediately after opening a new terminal is laggy/stuttery (~100-200ms per keystroke) for the first several commands. The lag does NOT go away just by continuing to type/run commands (tested across 5+ sequential commands). It only clears after a genuine, uninterrupted idle pause of a few seconds with zero input — after that, typing is instant (~10-30ms) for the rest of the session. ### What I ruled out (instrumented reproduction, not guesswork) - bash history file size — cleared ~/.bash_history entirely, identical lag. - ble.sh's `term_modifyOtherKeys_external` bleopt — changed live, no effect. - ble.sh's async history-array-construction / multiline-history-fixup idle tasks — forced both synchronous via a `blehook ATTACH!=...` hook, no improvement. - foot itself — reproduced identically in a bare synthetic pty (Python `pty.openpty()` + `bash -i`, no terminal emulator involved at all). ### What the lag actually corresponds to Traced via /proc/<pid>/wchan + child-process sampling: after every single command, Omarchy's default PROMPT_COMMAND chain spawns `mise` (hook-env), `starship` (2-4x per prompt, including the right-prompt call), `zoxide`, plus `stty` calls ble.sh makes around external command execution. This whole burst takes ~100-200ms combined in the first few commands after opening a terminal, and drops to ~10-30ms only after a real idle gap. Notably, the lag disappears entirely when the shell runs under `strace`, suggesting a timing-sensitive race rather than a fixed cost — possibly CPU governor / cgroup CPU-quota related rather than anything in mise/starship/zoxide/ble.sh's own code. ### Possibly related - #4087 (periodic stalls, delayed keystrokes, CPU governor toggling didn't help) - #3685 (mise hook overwritten by starship/zoxide — same rc chain, different bug) - #1684 (slow terminal/Nautilus launches on laptop, undiagnosed) Happy to share the pty reproduction script if useful.
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.