KernelHub Version & diagnostics
Four commands answer almost every “why is it doing that”, and three facts make almost any report answerable.
Which build is this
On the phone and in the console it is on the About screen. “Latest” is not a version. Two builds of 1.0.2 can behave differently, which is exactly why the build stamp is printed at the bottom of every page of this site too.
Can this machine work right now
One pass over the things that have to be true: is there a workspace, is the agent running, is a Runtime installed and usable, do the permissions allow what you are asking. It answers the whole question rather than one piece of it.
Why is nothing happening
Almost always one of three things, in this order:
- The agent is not running.
icloser agentsshows who is running and which workspace each is bound to. Nothing running means nothing will pick up the task. - It is running, bound to a different workspace.
Also
icloser agents. Switching workspaces in the console changes configuration; a Executor binds its workspace when it starts. Reach for this before anything else when a switch appears to do nothing. - It picked the task up and stopped for a permission.
icloser permsshows what this device may do, andicloser approval listshows what is waiting for you. A task that stops to ask is behaving correctly — it stops before doing the work, so nothing is half-done while it waits.
What it has been saying
The last lines from the resident agent. With -f it follows.
Asking for help
Three things make almost any report answerable. Without them, the first reply can only be a request for them.
- Version and build
icloser version, or the About screen. - The task id
Shown on the task's own card. With it we can point at the timeline and the diff instead of guessing from a description.
- What you expected, and what happened
Separately. “It didn't work” collapses those into one and loses the half that matters.
Where to send it: Support.
Something is wrong — which command first
Four commands, four different situations. Reaching for the wrong one is not harmless: two of them read only, and two change your machine or your queue.
When you need it "Can this machine work at all right now?" — the one command to run before you go looking for a reason.
What it actually does One pass over everything that has to hold at once: which build is installed, whether the gateway answers, whether this workspace's credential still works, whether an executor is actually running, and which runtimes this machine can reach. It reads; it changes nothing.
When you need it An employee says it cannot do something it is supposed to be able to do — a build, a test run, a package step.
What it actually does Probes the developer toolchain on this machine (Go, Java, Android, Xcode, Node …) and says, per tool, whether it is there and which version. It only runs --version and which: no model quota, no workspace credential, so it answers on a machine you have not set up yet.
When you need it probe just told you something is missing and you would rather not go find each installer yourself.
What it actually does Fills the gaps probe found, using this platform's own package manager. It is the writing half of the same pair — run probe first and read what it says, because this one changes your machine.
When you need it A task has been sitting in "running" with nothing happening — the machine that claimed it was closed, went to sleep, or its executor was replaced mid-run.
What it actually does Puts that task back on the queue so any qualified executor can pick it up. The task id does not change. This is the way out of a claim whose owner is never coming back — only the claiming machine could finish it, and it is gone.
Reaching into a task that is already out there
Every one of these takes the short id that icloser task list prints — you never have to go find the full one. Each also reads the new state back and prints it, so "this task cannot be paused right now" does not look identical to success.
| Command | What it does |
|---|---|
| icloser task cancel <id> | Stop it. A run already in flight stops at the executor's next heartbeat — the server cannot kill a process on your machine. |
| icloser task pause <id> | Hold it. Progress is kept: resume picks the same task up where it was, it does not start over. |
| icloser task resume <id> | Let a paused task carry on. |
| icloser task retry <id> | Same task (same id) back on the queue, run again from the top. It really starts a runtime and spends your own model quota. |
| icloser task recover <id> | Hand a stuck claim back to the queue. Use this one when nobody is working on it any more — see above. |
| icloser task followup <id> "the words you want to add" | Add an instruction to the same task — not a new one. The executor carries it into the work already under way. |
| icloser task accept <id> | Say the delivery is good. This is the human end of the loop. |
| icloser task choose <id> <the option you pick> | Answer a task that stopped to ask you which way to go. Your answer is written back into the same task and it carries on. |
| icloser task archive <id> | Move it out of the way. Nothing is destroyed. |
| icloser task unarchive <id> | Bring an archived task back into the list. |
| icloser task delete <id> --yes needs --yes | Gone from the list for good — not even --all brings it back. |
Scroll the table sideways →
retry, which really runs the task again. The rest only move a task between states.