Proof Portal

Sign in
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-492GitHub issuePublicDecided· Out of scope

Network panel reports TUN interface and fake IP as active Ethernet

Reported by aisensiy · filed Sep 16, 2026Closed upstream on 2026-10-12 by the bot omarchybot, as a duplicate (target not recorded).

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

Network panel reports TUN interface and fake IP as active Ethernetrevision 1 · captured 2026-09-28 21:23 UTC via poll

System details

  • Omarchy: 4.0.2-1
  • Kernel: Linux 7.1.9-arch1-2 x86_64
  • CPU: Intel Core Ultra 7 155H
  • GPU: Intel Meteor Lake-P / Arc Graphics
  • Network setup: NetworkManager with an active USB Ethernet adapter, plus Mihomo/Clash in TUN mode (Meta interface, fake-IP 198.18.0.1)

What's wrong?

The network panel reports the Mihomo TUN interface as the active Ethernet connection. It therefore shows the interface name Meta and fake/internal IP 198.18.0.1 instead of the underlying physical Ethernet connection and its real LAN IP.

Steps to reproduce

  1. Connect through a physical Ethernet interface.
  2. Enable Mihomo/Clash TUN mode with policy routing, so the probe address 1.1.1.1 is routed through the TUN interface.
  3. Open the network panel in the top-right bar, or run:
$ omarchy-network-status
ethernet Meta

$ omarchy-network-status --verbose
iface   Meta
ip      198.18.0.1
prefix  30
gateway 198.18.0.2
type    ethernet
speed   10000

The real physical route is still present:

$ ip route get 1.1.1.1
1.1.1.1 via 198.18.0.2 dev Meta table 2022 src 198.18.0.1 uid 1000

$ ip -4 route show default
default via 10.0.11.1 dev enp0s13f0u1u4c2 proto dhcp src 10.0.11.181 metric 100

Actual behavior

The panel identifies Meta as an Ethernet interface and displays its fake/internal IP. The real wired connection is not represented.

Expected behavior

The panel should show the underlying physical connection (enp0s13f0u1u4c2) and LAN IP (10.0.11.181). A TUN/VPN interface could be indicated separately, but should not replace the physical transport.

Likely cause

omarchy-network-status selects the interface with:

ip route get 1.1.1.1

and treats every non-wireless interface as Ethernet. Policy routing sends this fixed probe address through the TUN table, so the script selects Meta. Selecting an active physical NetworkManager device, or explicitly excluding TUN interfaces before falling back to the default route, should avoid the misclassification.

View raw text
### System details

- Omarchy: 4.0.2-1
- Kernel: Linux 7.1.9-arch1-2 x86_64
- CPU: Intel Core Ultra 7 155H
- GPU: Intel Meteor Lake-P / Arc Graphics
- Network setup: NetworkManager with an active USB Ethernet adapter, plus Mihomo/Clash in TUN mode (`Meta` interface, fake-IP `198.18.0.1`)

### What's wrong?

The network panel reports the Mihomo TUN interface as the active Ethernet connection. It therefore shows the interface name `Meta` and fake/internal IP `198.18.0.1` instead of the underlying physical Ethernet connection and its real LAN IP.

#### Steps to reproduce

1. Connect through a physical Ethernet interface.
2. Enable Mihomo/Clash TUN mode with policy routing, so the probe address `1.1.1.1` is routed through the TUN interface.
3. Open the network panel in the top-right bar, or run:

```console
$ omarchy-network-status
ethernet Meta

$ omarchy-network-status --verbose
iface   Meta
ip      198.18.0.1
prefix  30
gateway 198.18.0.2
type    ethernet
speed   10000
```

The real physical route is still present:

```console
$ ip route get 1.1.1.1
1.1.1.1 via 198.18.0.2 dev Meta table 2022 src 198.18.0.1 uid 1000

$ ip -4 route show default
default via 10.0.11.1 dev enp0s13f0u1u4c2 proto dhcp src 10.0.11.181 metric 100
```

#### Actual behavior

The panel identifies `Meta` as an Ethernet interface and displays its fake/internal IP. The real wired connection is not represented.

#### Expected behavior

The panel should show the underlying physical connection (`enp0s13f0u1u4c2`) and LAN IP (`10.0.11.181`). A TUN/VPN interface could be indicated separately, but should not replace the physical transport.

### Likely cause

`omarchy-network-status` selects the interface with:

```bash
ip route get 1.1.1.1
```

and treats every non-wireless interface as Ethernet. Policy routing sends this fixed probe address through the TUN table, so the script selects `Meta`. Selecting an active physical NetworkManager device, or explicitly excluding TUN interfaces before falling back to the default route, should avoid the misclassification.

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 14:03 UTC