What we verified with Codex and Space
Our first real client check covered ten MCP calls and work we could inspect in the website. Here is what happened and what that establishes.

Begin with work we can read back
On 11 September 2026, a Codex CLI session connected to the development version of Space and completed a ten-call acceptance check through its authenticated MCP server. The check covered a document, a task, an update, and the ability to read earlier state.
We chose a small workflow with observable results. If an agent says it saved something, we want to see the saved resource. If it says a task is done, we want the current task record to show that change.
The structured tool responses were checked independently of the agent’s final summary. The owner then refreshed the website and confirmed the two test items appeared there, including the updated task. This article summarizes that recorded development check; it is not a public production test.
What the ten calls covered
The calls exercised the same workspace through the agent connection and the website:
- Server and workspace information: protected access succeeded after authorization.
- Document creation: a handoff document was saved at revision 1 and read back with matching content and agent attribution.
- Retrying the same creation command: the response referenced the same document and revision. The retry did not create a second document.
- Task creation and reading: a task was saved at revision 1 with To do status, then read back.
- Task update and reading: the task moved to revision 2 with Done status, and its current result was read back.
- History: reading task revision 1 still returned its original To do state and body.
The scope of the ten-call development check
- Access · 2 callsInspect the workspaceRead protected server and workspace information after authorization.
- Document · 3 callsCreate, retry, readThe retry returns the same document at revision 1. Read back its saved content.
- Task · 5 callsSave and verify stateCreate, read, update to Done, read again, then inspect revision 1 in history.
After the tool calls, the owner refreshed the website and confirmed the saved document and updated task.
Keeping the earlier task revision gives a person a way to inspect what changed. Showing the same resource in the website also makes the agent’s work visible outside the conversation that created it.
What still needs its own check
The result supports a specific claim: a real Codex CLI session successfully used authorized document and task operations in the development environment. The acceptance record also leaves explicit follow-up work:
- Real-client revocation, reconnection, and token refresh need their own acceptance checks. Automated grant-enforcement tests cover a different layer.
- A second MCP client needs an independent connection and workflow test before we list it as verified.
- Memory extraction, relevance, and continuity across separate sessions need separate evidence. This document-and-task check did not measure them.
- A development integration does not establish production availability, operating capacity, or a supported self-hosted release.
A small result we can build on
Space’s direction is to keep documents, tasks, and memory available to the agents a person chooses. The first useful step is a dependable round trip: authorize an agent, save work, read it back, and inspect the result yourself.
That foundation gives us a concrete way to evaluate the next stage. We can save a decision, begin a separate session, retrieve its evidence, and check how the agent uses it. We will need to record failures and missing context as carefully as successful recall.
Space is in development. Public hosted sign-ups are not open yet. For now, these build notes and the public guides explain the work and its current boundaries.