Originally published at HOL

Introducing plori: a cloud computer for your Codex agent

What plori does

plori gives an AI agent its own computer in the cloud. Each agent gets a real disk and a real shell, with git, python3, node, curl, jq, etc on PATH, plus web search and page fetch, and it can install whatever else a task needs. It keeps all of it between sessions. Ask for a report today, open the same file next week. When an agent is idle it sleeps, and sleeping costs no compute.

The plugin connects Codex to that platform through plori's remote MCP server at https://api.plori.ai/mcp.

Two things ship in the plugin:

• The MCP server config (.mcp.json), pointing at the hosted endpoint. Auth is OAuth 2.1, negotiated on the first tool call, so there are no keys in the repo or in your Codex config.

• The plori skill (skills/plori/SKILL.md), which teaches Codex the actual working loop: connect, create an agent, invoke it and read the reply, answer human-in-the-loop requests, schedule deferred runs. It is the same text served at plori.ai/.well-known/agent-skills/plori/SKILL.md.

Nothing in the plugin runs local code or installs third-party software.

Who it helps

Developers whose agent work outlives the terminal. A build, a migration, a crawl, a long research pass: start it, close the laptop, read the result later. The run is not tied to your session.

Anyone who is tired of re-explaining context. The agent's disk persists, so notes, checkouts, and generated artifacts are still there next week. Session two starts where session one stopped instead of from an empty directory.

People who want their agent to have a second agent. Because the surface is MCP, Codex (or Claude Code, or your own framework) can create agents, drive them, and read their replies as ordinary tool calls.

It is not the right tool for everything. If the task is a thirty-second edit in a repo you already have open, local Codex is already the right answer, and adding a network hop just slows you down. plori earns its place when work is long, repeated, or needs to survive your terminal closing.

How to install and use

codex plugin marketplace add plori-ai/codex-plugin
codex plugin add plori@plori

Or connect the MCP server on its own, without the plugin:

codex mcp add plori --url https://api.plori.ai/mcp
codex mcp login plori

Sign-in is a one-time email code in the browser: the plugin path asks on your first tool call, the direct path at codex mcp login. You can also try an agent with no signup at all at plori.ai/agent.

Example workflow

Say you maintain a repo and you want release notes drafted.

1. In Codex: \\\_"Create a plori agent called\\\_ releasenotes\\\_, have it clone https://github.com/liu1700/orlop, read every commit since the last tag, and draft notes to notes/latest.md." Codex calls create_agent, then invoke_agent. The agent clones the repo on its own disk and works there.

2. invoke_agent waits about a few seconds for the turn. Real work like this usually runs longer. The run keeps going whether or not your Codex session is still open.

3. If the agent hits something it should not decide alone (an ambiguous breaking change, say), it asks. That surfaces as list_pending_inputs, and you answer with answer_pending_input without restarting the run.

4. The tag lands tonight and you would rather not sit and wait for it. schedule_run fires a single deferred run, either at a fire_at timestamp or after delay_seconds: "re-read the tags at 22:00 and refresh the notes if a new one appeared."\\\_ It wakes the agent at that time, runs the turn, and lets it go back to sleep afterwards.

5. Tomorrow, try asking \\\_"What changed since the notes you wrote yesterday?"\\\_

create_agent is get-or-create by name, so asking for releasenotes again returns the existing agent instead of a duplicate.

Why it pairs with HOL Guard

Guard and plori solve adjacent halves of the same problem, and neither replaces the other.

Guard governs the boundary on your machine. It evaluates what your local agent is about to do (secret exposure, prompt injection, unsafe shell commands, malicious packages, MCP risk) and allows, blocks, or pauses it before it runs. plori changes \\\_where\\\_ the risky part runs: work moves to an isolated cloud machine that is not your laptop, and deleting the agent deletes its disk with it.

We built the plugin to give Guard as little to be suspicious about as possible. There is no local code, no postinstall step, and no credential in the repo. It is one hosted endpoint reached over OAuth. The HOL Plugin Scanner runs in CI on every push to the plugin repo, pinned by commit SHA, with min_score: 80 and fail_on_severity: high, and uploads SARIF to GitHub code scanning. If a change ever drops the trust score, the build fails before anyone can install it.

One honest limit: Guard cannot see inside the remote machine. What plori gives you out there is isolation, a delete button, and a credit balance that stops runs when it hits zero. The sane posture is to treat a plori agent like a machine you own but do not trust: hand it the narrow credentials the task needs (per-agent environment variables exist for exactly this), not your whole keychain.

• Site: plori.ai

• MCP connect guide: plori.ai/mcp

• Plugin source: github.com/plori-ai/codex-plugin