A mature X11 daily driver
Openbox-class window management with ICCCM/EWMH interoperability, crash-safe client adoption, and regression-by-regression compatibility evidence.
Open sourceRust · X11 + WaylandDaily-driver dogfooding
nobox
A small, predictable, Openbox-inspired window manager and Wayland compositor with one desktop policy and two deliberately separate backends.
123
waylandxwayland ready14:32$ nobox --backend wayland doctor --nested-x11
renderer pixman ok
outputs 1 ok
config strict ok
$ nobox --backend wayland run --nested-x11
Super + dragmove
Alt + Tabcycle
Super + →workspace
The baseline
Old-school restraint. Modern implementation.
Openbox is the behavioral reference, not a dependency. Version 0.3.0 carries the same restrained stacking-desktop behavior across the mature X11 window manager and a new native Wayland compositor—without turning either display server into the internal model.
A native Wayland compositor
A Smithay backend brings the same focus, stacking, workspace, placement, decoration, menu, and session policy to native Wayland clients.
One strict configuration
Bindings, menus, workspaces, themes, and application rules live in one validated file. Typos fail loudly.
XWayland when you need it
Optional XWayland clients share the same core policy, with lifecycle recovery, clipboard and drag-and-drop bridging, scaling, and toolkit coverage.
Menus without a toolkit
Nested menus, XDG application discovery, live window and workspace lists, and bounded command-generated menus.
One policy, separate backends
X11 and Wayland are independently linked and packageable. The core stays toolkit-free, display-server-neutral, and contains no unsafe Rust.
The agent seat
Automation gets a seat. It does not get the keys.
nobox can expose structured desktop state, a trustworthy event stream, window-addressed input, and consented capture to an AI agent harness on X11, native Wayland, and XWayland. The boundary is part of the session, so control remains visible and enforceable.
Off by default
The person at the keyboard wins by construction.
Access is granted per executable. Windows can be hidden from agents entirely, agent activity is drawn by the window manager, and a physical kill chord always outranks synthetic input.
PER-EXECUTABLEGrant only the harness you intend to use.
VISIBLE STATEWM-drawn indicators cannot be hidden by the agent.
HUMAN OVERRIDEPhysical input and the kill chord take priority.
Release history
One desktop policy now speaks two display protocols.
Version 0.3.0 adds the native Wayland path without displacing the established X11 session. The release passed the complete developer gate and a 68-test CTest suite; direct DRM/KMS remains explicitly pre-release until its guarded hardware record is complete.
v0.3.0
X11 stays the mature daily-driver path. Wayland ships as a working nested baseline with a clearly marked hardware gate.
Release highlights
Native Wayland
Smithay-powered rendering, input, workspaces, menus, sessions, live configuration, and bounded protocols for modern toolkits.
Independent backends
A tiny selector launches separately linked X11 or Wayland executables. Either backend—and XWayland—can be omitted at build time.
Wayland Agent Seat
The existing deny-by-default grant, observation, capture, accessibility, input, consent, and human-override model now spans both backends.
Try it safely
Choose a backend. Start nested.
X11 is the compatibility default. Try it in Xnest, or select the Wayland backend for its isolated nested renderer. Keep the direct DRM/KMS session for guarded hardware testing.
git clone https://github.com/kekePower/nobox.git
cd nobox
cmake --preset dev
cmake --build --preset dev
cmake --build --preset test
# Run a disposable nested desktop
Xnest :2 -geometry 1280x800 -ac &
DISPLAY=:2 ./build/dev/cargo/debug/nobox doctor
DISPLAY=:2 ./build/dev/cargo/debug/nobox
DISPLAY=:2 xterm &
# Or verify the native Wayland backend, still nested
./build/dev/cargo/debug/nobox --backend wayland doctor --nested-x11
./build/dev/cargo/debug/nobox --backend wayland run --nested-x11Architecture
Policy is neither X11 nor Wayland.
Protocol-neutral behavior lives apart from both display backends. The user-facing nobox command selects an independently linked session executable, while optional settings, panel, XSMP, semantic-helper, and MCP companions stay outside the manager’s failure boundary.
nobox-coreProtocol-neutral focus, stacking, workspaces, geometry, and work areas.
nobox-x11Independent X11 session executable with ownership, client management, EWMH, and XSMP handoff.
nobox-waylandIndependent Smithay compositor with rendering, input, DRM/KMS, protocols, and optional XWayland.
nobox-commonBackend-neutral CLI, autostart, panel, signals, session supervision, and Agent Seat boundaries.
nobox-configStrict TOML models with validated, format-preserving edits.
nobox-desktopBounded XDG desktop-entry discovery and safe application launching.
Read deeper
The evidence is part of the project.
Compatibility claims, Wayland’s remaining hardware gate, security boundaries, configuration behavior, and agent access are documented alongside the implementation.
GPL-2.0-only. Openbox behavior is studied and tested; the Rust implementation is written independently, contains no unsafe code, and keeps UI toolkits out of the core.
Explore nobox