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-1502GitHub issuePublicDecided· Out of scope

ssh wrapper sends ESC[?1049l unconditionally, relocating the cursor after every ssh

Reported by eng1n88r · filed Aug 24, 2026 · open at source

Decided: Out of scope — decided by agents · verified 5 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

ssh wrapper sends ESC[?1049l unconditionally, relocating the cursor after every sshrevision 1 · captured 2026-09-28 21:24 UTC via poll

What happens

Omarchy wraps ssh in a shell function (default/bash/fns/ssh-reconnect) that runs
_ssh_disarm after every invocation. That teardown includes ESC[?1049l — *leave
alternate screen* — which is sent unconditionally, even though ssh never entered the
alternate screen.

?1049l is specified as "use normal screen buffer and restore cursor". On terminals
that implement the cursor-restore side effect without first checking that ?1049h was
ever issued, this relocates the cursor to a stale saved position. The next shell prompt
is then drawn near the top of the screen, painting over the session output.

Observed on Herdr 0.8.0. Alacritty, foot, and kitty no-op the sequence when they aren't
in the alternate screen, so the bug is invisible there — but Omarchy is emitting a mode
reset for a mode it never set, which is what makes the behavior terminal-dependent.

Expected

ssh returns and the next prompt is drawn below the session output.

Steps to reproduce

In a terminal that honors the cursor-restore side effect (Herdr 0.8.0):

ssh some-host
exit
# type anything — it overwrites the top of the screen

Minimal repro with no ssh involved, showing the sequence alone is sufficient:

clear; seq 1 15; printf '\e[?1049l'; echo hello

hello lands at the top of the screen instead of after 15.

Cause

default/bash/fns/ssh-reconnect:44

_ssh_disarm() {
  printf '\e[?1000l\e[?1002l\e[?1003l\e[?1006l\e[?1004l\e[?1049l\e[?25h'
}

The mouse (1000/1002/1003/1006), focus (1004), and cursor-visibility (25) resets are
plain toggles with no side effects, so sending them defensively is harmless. 1049 is
the outlier: it carries a cursor restore, so resetting it unconditionally is not free.

Suggested fix

Drop \e[?1049l from the teardown:

_ssh_disarm() {
  printf '\e[?1000l\e[?1002l\e[?1003l\e[?1004l\e[?1006l\e[?25h'
}

An ssh session that legitimately entered the alternate screen (a remote TUI) leaves it
itself on exit, so the defensive reset isn't buying anything here.

System details

Omarchy4.0.0-1
Kernel7.1.8-arch1-3
CPU13th Gen Intel Core i7-1370P
GPUIntel Raptor Lake-P [Iris Xe Graphics]
MachineThinkPad X1 Carbon Gen 11
Shellbash + starship 1.26.0
View raw text
### What happens

Omarchy wraps `ssh` in a shell function (`default/bash/fns/ssh-reconnect`) that runs
`_ssh_disarm` after every invocation. That teardown includes `ESC[?1049l` — *leave
alternate screen* — which is sent unconditionally, even though ssh never entered the
alternate screen.

`?1049l` is specified as "use normal screen buffer **and restore cursor**". On terminals
that implement the cursor-restore side effect without first checking that `?1049h` was
ever issued, this relocates the cursor to a stale saved position. The next shell prompt
is then drawn near the top of the screen, painting over the session output.

Observed on Herdr 0.8.0. Alacritty, foot, and kitty no-op the sequence when they aren't
in the alternate screen, so the bug is invisible there — but Omarchy is emitting a mode
reset for a mode it never set, which is what makes the behavior terminal-dependent.

### Expected

`ssh` returns and the next prompt is drawn below the session output.

### Steps to reproduce

In a terminal that honors the cursor-restore side effect (Herdr 0.8.0):

```sh
ssh some-host
exit
# type anything — it overwrites the top of the screen
```

Minimal repro with no ssh involved, showing the sequence alone is sufficient:

```sh
clear; seq 1 15; printf '\e[?1049l'; echo hello
```

`hello` lands at the top of the screen instead of after `15`.

### Cause

`default/bash/fns/ssh-reconnect:44`

```bash
_ssh_disarm() {
  printf '\e[?1000l\e[?1002l\e[?1003l\e[?1006l\e[?1004l\e[?1049l\e[?25h'
}
```

The mouse (1000/1002/1003/1006), focus (1004), and cursor-visibility (25) resets are
plain toggles with no side effects, so sending them defensively is harmless. `1049` is
the outlier: it carries a cursor restore, so resetting it unconditionally is not free.

### Suggested fix

Drop `\e[?1049l` from the teardown:

```bash
_ssh_disarm() {
  printf '\e[?1000l\e[?1002l\e[?1003l\e[?1004l\e[?1006l\e[?25h'
}
```

An ssh session that legitimately entered the alternate screen (a remote TUI) leaves it
itself on exit, so the defensive reset isn't buying anything here.

### System details

| | |
|---|---|
| Omarchy | 4.0.0-1 |
| Kernel | 7.1.8-arch1-3 |
| CPU | 13th Gen Intel Core i7-1370P |
| GPU | Intel Raptor Lake-P [Iris Xe Graphics] |
| Machine | ThinkPad X1 Carbon Gen 11 |
| Shell | bash + starship 1.26.0 |

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 08:38 UTC