eyeclaw.app is the advanced operator layer for your Eyeleven workspace. It is a separate site from the desktop OS, built for one job: running workspace operations directly, watching them execute, and reviewing exactly what happened afterwards.
Most people never need it. It exists for the person in your business who wants to drive the workspace from a command line rather than through windows, and who wants an auditable record of every instruction that was issued.
Where each thing belongs
The two surfaces do not overlap, and it is worth being clear about the split before you open either one.
The desktop OS at app.eyeleven.com is where your business runs day to day. You deploy OmniForces there, build workflows, connect WhatsApp and your other channels, manage your Knowledge Base, read conversations, and handle billing and plan changes. If you are setting something up, configuring it, or paying for it, you are in the OS.
eyeclaw.app is the operator layer on top of that. It does not deploy Forces, connect channels, or change your plan. It issues commands against the workspace the OS already configured, and it shows you the resulting record. Every page carries a Back to OS link for exactly this reason.
There is also an EyeClaw cockpit inside the desktop OS, which is a different thing again: that window is where you configure one OmniForce — its personality, memory files, skills, heartbeat, and connections. See EyeClaw for the cockpit and Skill Hub for skills.
Signing in
eyeclaw.app uses the same Eyeleven account as the rest of the platform — the same email, the same password, the same workspace membership. There is no separate registration.
Because eyeclaw.app is a different domain, your session does not travel across from eyeleven.com automatically. Visiting it while signed out sends you to the normal Eyeleven sign-in page and returns you to the page you asked for. Once inside, the header shows the workspace you are connected to and your role in it, which determines what you are allowed to decide.
The header also carries a runtime status indicator. It reads Operational, Safe mode, Disabled, or Runtime unknown — the last of these meaning the control plane could not reach the runtime at all, rather than that everything is fine.
The surfaces
The left rail holds eight surfaces.
Overview
The landing page: runtime health plus recent activity. It summarises the most recent 25 executions in your workspace — how many succeeded, how many are in flight, how many were stopped by policy — and shows the state of the runtime, the approval gate, the MCP gateway, and the action registry.
Every figure is computed from what the runtime actually returned. If a panel cannot load, that panel is replaced by the failure and its error code rather than by a zero.
Command Deck
Where you issue instructions. You type what you need in plain language and choose one of two buttons:
- Run resolves your text to a single action and executes it.
- Orchestrate treats your text as a goal, plans it into several actions, and runs them together.
Commands are accepted immediately and execute in the background. Neither button blocks the input, so you can fire several in a row and watch them run at the same time. Each one is recorded with its risk level, the action it resolved to, and its full result. Pressing Enter runs; Ctrl+Enter (or Cmd+Enter) orchestrates.
An Actions rail on the right lists everything the runtime can do. Selecting one loads a working example into the command box, which is the quickest way to learn the vocabulary.
If your text cannot be mapped to a registered action, EyeClaw does not guess. It says so and shows you the list of commands it does understand.
Tasks
The full execution board for the workspace — every recent run, whoever started it, not just the ones from your own session. Expand a row for its output or its error. Steps that belong to an orchestration are tagged, so a fan-out reads as one piece of work rather than as unrelated rows.
Work is queued and drained in the background. A workspace runs up to 3 tasks at once and may have up to 20 waiting; beyond that, EyeClaw asks you to let some finish first. There is also a limit of 30 executions per minute per person.
One honest limitation: the queue lives in the running process. Tasks outlive the request that created them, but not a restart of the service. If a restart interrupts queued or running work, those rows are marked as failed rather than left showing as if they were still going.
Orchestrations
The history of multi-step runs. Each card shows the goal, how many steps succeeded, how long the whole thing took, and how every individual step ended.
Orchestration works like this: you give a goal, and a plan of between two and five registered actions is produced for it. Those actions then run in parallel, each as an ordinary task passing every gate on its own — orchestration grants no extra powers. Results are merged back into the parent record when the last step finishes.
The plan comes from the model. That is worth saying plainly, because it has two consequences you should know about:
- The steps are chosen at run time and are specific to your goal, so read them before trusting the result. The planner can only pick from the registered action list; an invented action name is discarded.
- If the model is unreachable or returns something unusable, a fixed fallback plan runs instead. The fallback is a standard workspace briefing — workspace summary, list Forces, list leads, summarise recent conversations. It did not interpret your goal, so its steps may not address what you asked for.
Every card is labelled with which planner produced it: LLM plan or fallback plan. If you see fallback plan, treat the result as a general briefing, not as an answer to your goal.
This surface shows the most recent 50 orchestration runs. Older ones still exist in the audit log but fall outside this window.
Approvals
The queue of commands that are waiting on a human. A parked command is shown with the exact input it would run with, because approving something you cannot see is not approval.
- Approve and run replays that stored input through the entire pipeline again — every permission, module, and risk check runs a second time. Approval releases only commands the policy says require approval; it can never unlock something the policy blocks outright.
- Reject closes the command permanently. It will not run.
Either decision is recorded against your account alongside what the command did.
Only workspace owners and admins can decide. Other roles can see what is waiting and read the input, but the buttons are not shown to them — and the refusal is enforced on the server, not just hidden in the interface.
Skill Hub
Where you decide what each OmniForce is capable of. This has its own article: Skill Hub.
Actions
The capability catalogue: every action the runtime can resolve, with its risk level, its category, the input it expects, and worked examples you can copy into the Command Deck.
This list is the whole truth about what EyeClaw can do. The runtime resolves every command through this same registry, so an action that is not in this list cannot be run by anyone, through any phrasing. There is deliberately no raw shell, no direct database access, no credential handling, no bulk messaging, no deletion, and no payment action anywhere in it.
Today the registry holds thirteen actions, none of them high or critical risk. Nine are read-only. Three more are marked draft-only, meaning they produce nothing live. The remaining one pauses an OmniForce, and therefore waits for approval.
Audit
The execution log for your workspace, newest first, including the commands that were refused. Each row carries the time, status, risk level, resolved action, command text, duration, and error.
You can filter by status, by risk level, or by searching the command text, and then export exactly the rows you are looking at as a CSV.
The log loads 50 entries at a time. A Load 50 older button fetches the next page on demand, and once you reach the end it says so rather than leaving you wondering whether more exists. This is deliberate: an audit surface that implies completeness it does not have is worse than one that names its limits.
What EyeClaw is allowed to do on its own
Every action carries a risk level, and the runtime applies the following policy to all of them. This is enforced in the runtime itself, not in the interface, so it holds no matter how a command is phrased or where it came from.
| Risk level | What happens |
|---|---|
| LOW | Runs automatically. Reading summaries, listing records, checking status. |
| MEDIUM, draft-only | Runs automatically. The action produces a draft, a preview, or an analysis with no live side effects, leaving the decision to you. |
| MEDIUM, with live side effects | Waits for approval. The command is parked with its validated input until a workspace owner or admin approves or rejects it. Nothing executes meanwhile. |
| HIGH | Blocked while safe mode is on. Safe mode is on by default. |
| CRITICAL | Never available through EyeClaw, under any setting. Deletes, exports, bulk sends, payments, credentials. |
Two points of detail worth having:
- A parked command is not a failed command. It keeps the exact input it was validated with, so approving it later runs precisely what was requested — not a re-interpretation of your original text.
- Today the action registry contains no HIGH or CRITICAL actions at all, so those two rows describe a policy that currently has nothing to block. They matter because they define the ceiling: capabilities cannot be added above that line without changing the policy itself.
Limits worth knowing
Stated plainly, so nothing surprises you later:
- Overview reasons about the most recent 25 executions; Audit and Orchestrations work in windows of 50, with older audit entries loading on demand.
- An orchestration plans between two and five actions, never more.
- 30 executions per minute per person, 3 running at once per workspace, 20 queued at most.
- Queued and running work does not survive a restart of the service; affected rows are marked failed rather than left hanging.
- Approvals can be decided by owners and admins only.
Getting started
- Sign in at eyeclaw.app with your usual Eyeleven account.
- Open Actions and read what the runtime can actually do. Select one to load its example.
- Go to the Command Deck and run it. Watch it land on the board.
- Try Orchestrate with a real goal, then open Orchestrations and check whether the card says LLM plan or fallback plan.
- Look at Audit afterwards. Everything you just did is there, refusals included, and can be exported.