KernelHub v1.0.2
How It Works

Nine things, in the order they happen

Each chapter is one concept in plain words: what it is, what it is not, and what KernelHub does with it. Every animation and table on this page shows something v1.0.2 ships today.

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
01

AI Employee

The one you hire. A named role — AI Developer, for example — with a definition, the skills it claims, the environment those skills need, the workspaces it is assigned to, the permissions it works under, and the tasks, memory and results that accumulate as it works.

It is not

It is not a chat session and not a model. Hiring one does not widen what can be done on your machine — permission still does that.

KernelHub

KernelHub keeps the Employee as an account-level thing: its role and skills are the same in every workspace it is assigned to, and the console reports whether its environment is actually ready.

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 →

AI Employee in Help
02

Agent

The intelligence the Employee works with: it understands the task, plans, reasons, calls tools and decides what to do next.

It is not

Deciding is not the same as being allowed. The Agent can propose a write; it cannot perform one.

KernelHub

KernelHub does not build its own Agent and never calls a model itself. It governs the Agents you already use, by putting every action they want through the Workspace, the Permission contract and the Executor.

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 →

Sending a task
03

Runtime

The model or runtime that carries the Agent's intelligence — Claude Code, Codex, Qwen Code, Antigravity (agy), MiMo and others, installed and signed in by you.

It is not

The Runtime is not the Employee. Switching it does not change who you hired, what they are allowed to do, or which workspace they work in.

KernelHub

The Runtime Router picks a Runtime that can actually take the task on this machine. Whichever one runs, its writes, edits and commands go through the same built-in Tool Server and are checked against your grants — not a prompt asking the model to behave.

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.

Runtimes in Help
04

Executor

The governed execution layer on your own machine: the icloser process. It carries out authorised actions — read, write, exec, build, test, git, artifact, device — and reports what happened.

It is not

It is not an agent. It has no intelligence of its own and no authority of its own; it is bounded by the Permission contract and the Workspace contract.

KernelHub

The Executor has its own gate: a command that reaches it without the grant it needs is refused before it runs, whichever model asked for it — and every action it takes is recorded.

AI Employee

The one you hire

Not a chat window, and not a Runtime.
Agent

The intelligence it works with

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

The model that carries the intelligence

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

The governed hands on your machine

It is not an agent. It has no intelligence of its own, and it obeys the Permission and Workspace contract.
Executor in the CLI reference
05

Workspace

A directory on your machine that a task is bound to. Tasks, permissions, memory and results are recorded per workspace.

It is not

A Workspace does not own the Employee; it is where the Employee is assigned to work. Workspaces do not reach into each other.

KernelHub

A task runs inside the workspace it was sent to, and nowhere else. Moving the directory keeps its identity; tasks, memory and files come along.

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.

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.

Live Workspace in Help
06

Permission

Six tiers — read, write, exec, web, push, delete/migrate — granted separately, per device and per workspace. Below them, two things no grant can open: your credentials, and writing outside the workspace.

It is not

A permission is not a suggestion to the model. It is checked by the Tool Server and the Executor's gate before the action runs.

KernelHub

A task that needs a tier it does not have stops before doing anything and asks. A grant for one task expires the moment that task ends.

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.
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.

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.

Permissions in Help
07

Local Execution

The work happens on the machine that already holds your code. Nothing is uploaded; what travels is the task text, progress, the diffs you chose to see, and your approvals.

It is not

It is not a remote terminal. Nobody types into your machine; the Executor applies allowed actions and nothing else.

KernelHub

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.
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.

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.

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.

Getting started
08

Mobile Approval

When a task reaches a WRITE, EXEC or other boundary it does not have, a card appears on the device you are holding, with the diff so far and the exact wording of what is being asked.

It is not

The phone is not an Executor and not a Runtime. It sends tasks, approves, and reads results.

KernelHub

Approve once and the same task resumes — nothing is re-run and nothing was done while you were deciding.

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.

iPhone / Android

Task · Approval · Result

The phone is not an Executor. It sends tasks, approves, and reads results.

“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
Approval in Help
09

Evidence: Diff · Artifact · Result

Done is a claim; evidence is what makes it true. Each task ends with a diff attributed to that task, any artifact it produced, and a result that is done, revised or stopped — never a false “complete”.

It is not

A result is not a chat summary. If a command was refused mid-task, the result says so.

KernelHub

The live diff streams from the Executor while the task is still running; the file list is attributed to the task, so other edits in the same workspace stay out of it.

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.

Results in Help Diff
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.

Try it against your own repository

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

Getting started Open the demo