KernelHub v1.0.2
KernelHub v1.0.2 · AI Employee Runtime & Governance Platform

AI Employees that actually work.
Govern every agent behind them.

KernelHub is an AI Employee Runtime & Governance Platform. You hire an AI Employee. Its Agent thinks. A Runtime such as Claude, Codex or Qwen carries that thinking. And an Executor on your own Mac, Linux or Windows machine carries out only the actions you allowed — then hands you the diff, the artifact and the result.

Download Read the nine chapters Getting started iOS App Store ↗
macOS · Linux
$ curl -fsSL https://icloser.xyz/install | sh
Windows
PS> irm https://icloser.xyz/install.ps1 | iex

The shell command installs on macOS and Linux; the PowerShell one needs Windows PowerShell 5.1 or later. Installers, a portable package and signed binaries with checksums are on the download page.

LIVE DEMO
Animation: a task typed on a phone is queued by KernelHub Server, claimed by the executor on your own machine, which reads, modifies and tests the code; the diff returns to the phone as an approval card, you allow it once, and the task finishes. WORKSPACE 1/1 · POLL 3s · NO UPLOAD KERNELHUB v1.0.2 · LOCAL EXECUTION T+00:02 T+00:05 T+00:09 T+00:13 9:41 Live Workspace Modifying DateUtils.kt +8 −3 read PermToggle.kt edit DateUtils.kt exec ./gradlew test BUILD OK Send a task… lift labels to constants PERMISSION · EXEC Run the Gradle build? + LABEL_TODAY = "Today" + LABEL_YESTERDAY = … − "Today" Allow just this once Task complete · +8 −3 Your device QUEUE · PERMISSIONS KernelHub Server Queues it, holds permissions ~/android-app · DateUtils.kt 050607 080910 1112 +8 −3 Reading Modifying Testing $ ./gradlew :app:assembleDebug BUILD SUCCESSFUL in 41s Your own machine

Scroll sideways to see the whole chain →

Every frame maps to a step KernelHub performs in v1.0.2. The file, the counts and the build line come from a task that actually ran.

13registered runtimes
6permission tiers
2kinds of action refused whatever you grant
0lines of your code uploaded
What KernelHub is

Execution + Governance, in one product

Two things have to be true at once: the AI Employee gets real work done, and every agent behind it stays governed. KernelHub is built so that neither one is left to trust.

It is

An AI Employee Runtime & Governance Platform

It organises who works (the AI Employee), lets the intelligence run on whichever Runtime fits, keeps every action inside a Workspace and a Permission contract, executes on your own machine through an Executor, and keeps the evidence.

AI Employees can finish work.Every agent behind them can be governed.
It is not
  • Not a model — it never calls one itself.
  • Not a single agent — it governs the agents you already use.
  • Not a Runtime launcher — a Runtime is one part it schedules, not the product.
  • Not a CLI wrapper — the CLI is one door into KernelHub, not KernelHub.
  • Not a remote terminal — nothing types into your machine; only allowed actions land on it.
Four words, kept apart

Employee · Agent · Runtime · Executor

Most agent products fold these into one thing. KernelHub keeps them separate, because the whole point is that the one who thinks is not automatically the one who is allowed to act.

AI Employee

The one you hire

A role with a definition, skills, an environment, a workspace assignment, permissions, tasks, memory and results. Example: an AI Developer. You hire a role, not a model.

Not a chat window, and not a Runtime.
Agent

The intelligence it works with

Understanding, planning, reasoning, calling tools, deciding. The Agent is the thinking part of the Employee's work.

Thinking does not grant it the right to touch your machine.
Runtime

The model that carries the intelligence

Claude, Codex, Qwen, Antigravity, MiMo and others. It can be switched. Switching the Runtime does not change the Employee — its role, skills, workspace, permissions and task context stay.

Not the Employee, and not the thing that executes.
Executor

The governed hands on your machine

A controlled execution layer on your own Mac, Linux or Windows machine. It carries out authorised actions — read, write, exec, build, test, git, artifact, device — and nothing else.

It is not an agent. It has no intelligence of its own, and it obeys the Permission and Workspace contract.
In one breath
I hire an AI Employee. Its Agent thinks. A Runtime carries the thinking. An Executor on my computer does only what I allowed. KernelHub organises, governs, and keeps the evidence.
How the pieces connect

From you to the result — and where the phone stands

Diagram: you direct an AI Employee; its Agent and skills work through KernelHub Governance (Workspace, Permission, Environment, Memory, Runtime Router) to a Runtime and then an Executor on your Mac or Windows machine, which returns a diff, an artifact and a result. A second lane shows iPhone and Android sending tasks and approvals to KernelHub and reading results — the phone is never an Executor. You AI Employee Agent / Skills KernelHub Governance Workspace Permission Environment Memory Runtime Router Runtime Executor Your Mac / Windows Diff · Artifact · Result iPhone / Android Task · Approval · Result The phone is not an Executor. It sends tasks, approves, and reads results. Every box exists in v1.0.2. Nothing on this diagram is a placeholder. KERNELHUB v1.0.2 · CONCEPT MAP
Why KernelHub

Intelligence does not equal authority.

Traditional agent products fuse three things into one: the AI's decision, the system's permissions, and execution on your machine. If the model decides, it also acts. KernelHub takes them apart.

The usual agent product

Decide, get permission, execute — one blob

The same process that reasons about your code is the process that has the keys to it. Every mistake in judgement is immediately a change on disk.

KernelHub

Decide in one place, act in another, approve on the device in your hand

The Agent decides. The Workspace bounds where. The Permission contract bounds what. The Executor is the only thing that acts, and only within both. Writing a file, running a command, building, pushing to git or operating a device must pass through Workspace + Permission + Executor.

The question has changed

It is no longer “is there a smarter agent?”. It is: who organises the work, who authorises it, who provides the environment, who bounds the workspace, who chooses the Runtime, and who confirms the work is actually done. That is what KernelHub is for.

You hire a role, not a model

In KernelHub you hire an AI Developer. Behind it the Runtime Router schedules whichever Runtime fits the task. The Employee's identity, role, skills, workspace, permissions and task context do not change when the Runtime does.

EMPLOYEE FLOW

Hire → Assign → Work → Approval → Artifact → Result

What an AI Employee's day looks like in KernelHub, end to end.

EMPLOYEE FLOW
Animation: an AI Developer is hired, assigned to a workspace, works by reading, editing and building, raises an approval card on the phone before running the build, produces an artifact, and reports a result with evidence. KERNELHUB v1.0.2 · EMPLOYEE FLOW 01 HIRE Hire AI Developer 02 ASSIGN Assign to a workspace 03 WORK Work read · edit · build 04 APPROVAL Approval on your phone 05 ARTIFACT Artifact app-debug.apk 06 RESULT Result done, with evidence AI Developer kotlin · gradle · git ~/projects/app read PermToggle.kt edit DateUtils.kt +8 −3 exec ./gradlew → ? 9:41 PERMISSION · EXEC Run the Gradle build? Allow once app-debug.apk 12.4 MB · sha256 ✓ +8 −3 · BUILD OK The build stops before it runs and asks on the device you are holding. The artifact and the result only exist because the Executor actually did the work.

Scroll sideways to see the whole chain →

AGENT GOVERNANCE

Where the intelligence stops and the authority begins

The Agent may decide anything. Only the Executor acts — and at a WRITE or EXEC you have not granted, it waits for you.

AGENT GOVERNANCE
Animation: an AI Employee's Agent decides on a write; the request passes through KernelHub Governance to a Runtime and on to the Executor; at the WRITE and EXEC boundary a Permission Gate stops it, an approval card appears on the phone, you allow it, and only then does the Executor apply the change on the local machine. INTELLIGENCE ≠ AUTHORITY AI Employee Agent KernelHub Governance Workspace Permission Environment Memory Runtime Router Runtime PERMISSION GATE Executor Your machine src/Auth.kt read ✓ Written on your machine +3 −1 READ src/Auth.kt WRITE src/Auth.kt 9:41 PERMISSION · WRITE Allow WRITE for this task? Allow READ passes on its own. A WRITE or EXEC you have not granted stops at the gate and goes to your phone. The Runtime never touches the disk; the Executor does, and only after the gate opens.

Scroll sideways to see the whole chain →

How It Works

Say it on the phone. It runs on your Mac.

This is the actual path a task takes in v1.0.2 — every node below exists in the shipping product.

01Your deviceiPhone · Android · Desktop
02TaskOne sentence, in your own words
03KernelHub ServerQueues it, holds permissions
04Runtime RouterPicks a runtime that is installed and can take the work
05ExecutorThe icloser process on your machine
06Your Mac or Windows machineWhere your code already lives
Reading Modifying Testing
07Live WorkspaceEvidence stream, as it happens
08DiffReal hunks, attributed to this task
09ApprovalA card on the device you are holding
10ResultDone, revised, or stopped — never a false ‘complete’
Motion is off — every step is shown at once.
Read the nine chapters
Product

Four things it actually does

Everything below ships in v1.0.2. How far it has been verified end to end depends on the platform: macOS — on real machines; Linux — in containers, real-machine verification still pending; Windows — on real machines. Nothing on this page describes work in progress.

Local execution

The agent runs where your code already is

A small executor (icloser) watches a workspace on your own machine and drives the CLI runtime you already have installed — Claude Code, Codex, Antigravity (agy) and others. There is no cloud sandbox, no repository upload, no source mirror.

Permission contract

Six tiers, checked before anything runs

Read, write, execute, web, push and delete/migrate are granted separately, per device and per workspace. Whichever runtime is working, its writes, edits and commands go through KernelHub's built-in Tool Server and are checked against those grants and the workspace boundary before they run — not a prompt that asks the model to behave.

Live workspace

Watch it work, line by line

While a task runs you see the evidence stream — files read, commands run, files changed — and a live diff with real hunks. Changes are attributed to the task, so other edits in the same workspace stay out of it.

Approval on your phone

Decisions come to you, not the other way round

When a task needs a tier it doesn't have, it stops before burning a run and raises a card with the diff so far and the exact wording of what it is asking for. Approve once and the same task resumes.

In practice

Two tasks, start to finish

Both of these are things v1.0.2 does today. Nothing here is a mock-up of a future feature.

“In PermToggle.kt, the three labels are hard-coded — lift them to constants. Then build to check nothing broke.”

  1. Sent from the phoneTyped into the composer, queued for the workspace
  2. Executor picks it upThe machine holding the Android repo claims the task
  3. Reads PermToggle.ktEvidence stream shows every file it opens
  4. Modifies itLive diff appears while it is still working
  5. Runs the buildGradle runs locally; output streams back
  6. Approval card on the phoneCarries the diff — +8 −3, with the hunk
  7. ResultYou approve, and the same task finishes

“Add an install section to README.md, and keep the tone of the rest of the file.”

  1. ReadingIt reads the file before writing anything
  2. ModifyingEdits land on disk on your machine
  3. Live DiffYou watch the paragraphs appear, line by line
  4. ResultNo approval needed — write was already granted
Runtimes

13 runtimes — and who actually holds each of the six tiers

Granting a permission and something enforcing it are two different things. This table is generated from the live registry: every runtime is asked, tier by tier, whether that grant really lands. Nothing here is typed in by hand.

RuntimeReadWriteExecWebPushDeleteStatus
claudeKernelHubruntimeruntimeKernelHubKernelHubKernelHubSUPPORTED
codexKernelHubruntimeruntimeKernelHubKernelHubKernelHubSUPPORTED
mimoKernelHubKernelHubKernelHubKernelHubKernelHubKernelHubSUPPORTED
opencodeKernelHubKernelHubKernelHubKernelHubKernelHubKernelHubSUPPORTED
qwenKernelHubKernelHubruntimeKernelHubKernelHubKernelHubSUPPORTED
acpKernelHubKernelHub—KernelHubKernelHubKernelHubNOT READY
agyKernelHubKernelHubKernelHubKernelHubKernelHubKernelHubNOT READY
codebuddyKernelHubKernelHubruntimeKernelHubKernelHubKernelHubNOT READY
geminiKernelHubruntimeruntimeKernelHubKernelHubKernelHubNOT READY
kimiKernelHubKernelHubKernelHubKernelHubKernelHubKernelHubNOT READY
mcpKernelHubKernelHub—KernelHubKernelHubKernelHubNOT READY
ohmypiKernelHubKernelHub—KernelHubKernelHubKernelHubNOT READY
piKernelHubKernelHubKernelHubKernelHubKernelHubKernelHubNOT READY
runtime

The runtime has its own verifiable switch and KernelHub passes it. Verified by actually building the argv, not by reading its docs.

KernelHub

The runtime has no switch of its own for this tier, so this cell is held by the outer OS boundary KernelHub puts around the runtime process — seatbelt on macOS, Landlock on Linux, both on by default; on Windows it is off by default in this release, and a Windows machine shows a gap here instead. It is an optional hardening layer, not something the work depends on; whatever this cell says, writes, edits and execs still go through the Tool Server against your grants and the workspace boundary.

—

Nobody on this machine can prove this tier is held. The runtime is marked NOT_READY — that is recorded, not a stop sign: it still takes work, and every write, edit and command still goes through your grants, the workspace boundary and the exec rules.

Why this table is public
A table that prints SUPPORTED when nobody can prove the boundary is held is worse than no table. So this one shows who holds each tier and prints a gap as a gap. A gap does not stop the work — whatever you grant, only two things are refused outright: touching credentials, and writing outside the workspace.

That outer OS boundary is an optional hardening layer, not something your work depends on. It is drawn on macOS (seatbelt) and Linux (Landlock); on Windows it is off by default in this release, so a Windows machine shows more gaps. When it cannot be drawn the work still runs — the cell just shows the gap. The table is computed per machine, and we would rather say that than imply it is universal.

Live Workspace

Not a spinner. The actual diff.

Animation: a real hunk in DateUtils.kt is written line by line — two lines removed, six added — while the +8 −3 counters fill. LIVE DIFF · 1 FILE DateUtils.kt +8 −3 050607 080910 1112 @@ -5,4 +5,9 @@ import java.time.ZoneId import java.time.format.DateTimeFormatter - fun label(d: LocalDate) = "Today" - // FIXME hard-coded + private const val LABEL_TODAY = "Today" + private const val LABEL_YESTERDAY = "Yesterday" + fun label(d: LocalDate) = when { + d == today -> LABEL_TODAY Streamed from the executor while the task was still running. Attributed to this task

Real output from a task issued on a phone and executed on a laptop.

Attributed to the task

Files already modified before the task started, or changed by another process while it ran, are counted separately and kept out of the task's diff.

Evidence, not narration

Read / command / edit events as they happen. Rows that come from filesystem watching are dimmed and hedged — they say a file changed, not who changed it.

Replay after the fact

Every task keeps its timeline and diff. Open a finished task and read what it did, in order.

Live Workspace guide
Security

The boundary is the product

Animation: five permission tiers light up in turn while the sixth — delete and migrate — stays dark, above a bar for what no tier ever opens: your credentials. Read Write Exec Web Push Delete CREDENTIALS · ALWAYS DENIED Credential paths stay blocked no matter which tier you grant. Delete / migrate is never on by default — it stays dark until you grant it, for one task.
Source stays local

Your repository is never uploaded

Execution happens on your machine. What crosses the network is task text, progress, diffs you chose to see, and approvals.

Credentials

Credential paths that no grant can open

Credential paths — SSH keys, cloud config, .env files, keychains — and high-risk operations are denied independently of what you granted. The list does not change when you approve a tier.

Task-scoped grants

“Just this once” actually means once

A permission approved for a task applies to that task only, in that workspace, and expires the moment the task reaches a terminal state — by read-time evaluation, not by a cleanup job.

Unenforceable boundaries

If it can't be held, you get told

When a task would touch the delete/migrate boundary on a runtime that cannot express a deny list, KernelHub stops before doing anything and asks you to release that one run explicitly. Approving it grants no permission tier.

Workspace isolation

Workspaces do not reach into each other

A task runs inside the workspace it was sent to. Permissions are recorded per device and per workspace; there is no global switch.

Non-interactive by design

No prompt that nobody can answer

Runtimes normally stop and ask a terminal that has no human in front of it. KernelHub moves that decision to a card on a device you actually hold.

Data handling is described in the Privacy Policy. Terms of use are in the Terms of Service.

Try it against your own repository

The demo runs entirely in your browser with no account. The real thing needs Node.js LTS (with npm) installed first, then one command on the machine that holds your code.

Getting started Open the demo