Skip to main content

​
Kernel — Eyes and Hands

Kernel CLI is where AI meets the operating system. It reads the structures the OS already maintains, acts through the strongest available capability, and falls back to rendered pixels only when structure is absent.

Kernel CLI documentation

Read the canonical installation, workflows, platform boundaries, safety model, and command reference.

​
Eyes: Structured Perception

The first question is not “what does the screenshot look like?” It is “what does the machine already know?”
The eyes are broad because desktop failure is not always a visual problem. A missing app may be a crashed process. A failed action may be a permission or session problem. A network dialog may be the visible symptom of a proxy, route, or service state.

​
Hands: Capability-First Action

Kernel CLI chooses the most semantic available write path:
The preferred loop preserves the state identity that produced the target:
The dry run answers which target and write backend would be used. The snapshot guard refuses stale state instead of blindly applying an old handle to a changed screen.

​
Semantic Does Not Mean Infallible

Accessibility is stronger than a coordinate guess when an app exposes a useful semantic tree, but not every element wires every advertised action. Custom renderers, games, canvases, decorative links, hidden or throttled windows, and incomplete accessibility implementations may require another path. The rule is therefore:
It is not:
Kernel CLI keeps OCR, screenshots, pointer input, and stricter no-focus or no-cursor policies available for those differences.

​
More Than Desktop Automation

The body also senses the machine that carries the desktop:
This is the difference between merely moving a cursor and understanding the conditions around an action. The agent can diagnose before it acts.

​
Cross-Platform Body, Platform-Specific Senses

Kernel CLI offers one behavioral order across three operating systems, but the body is not identical on each one:
  • macOS exposes the broadest native observation and control surface.
  • Linux depends on the interactive desktop, AT-SPI, display server, and helper availability. Pure Wayland may restrict global input or capture.
  • Windows centers on UI Automation and Win32 in the interactive user session, with OCR dependent on language support.
kernel-cli --json doctor is the live answer. A platform label alone is never enough to prove that a sense or action is available in the current session.

​
Browser Tools and Kernel Tools

Browser DOM/CDP tools and Kernel CLI are complementary: Use the browser-native surface for browser internals. Use Kernel CLI when the workflow crosses applications or needs OS state. A workflow can use both.

​
The Harness Holds the Reins

Direct Kernel CLI is raw capability. NIIA places a human authorization boundary in front of control:
The capability body and the authorization harness are deliberately separate. See The Harness for that boundary.

​
The Expanded Interface

The expanded being can now move across several complementary surfaces:
  • Terminal: interactive CLI sessions and tools.
  • Operating system: Kernel CLI observation, control, and machine telemetry.
  • Remote machines: Monolex transport and headless session surfaces.
  • External services: MCP and CLI integrations.
The question is not whether the being has eyes and hands. The useful question is whether it can show what it saw, which capability it chose, who authorized the action, and how it verified the result.

Kernel CLI Workflows

Follow the observe, dry-run, act, verify, and NIIA-gated loops.

Kernel CLI Reference

Inspect commands, permissions, platform behavior, audit, and MCP.