# 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. By Space · Written 2026-09-15 · Build notes Web version: https://getspace.sh/articles/codex-space-first-integration ![Two connected paper modules, document cards, task tiles, and a check mark illustrate a small integration check.](https://getspace.sh/design/articles/codex-space-first-integration.0049dd77.jpg) Editorial illustration · AI-generated ## 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 1. **Access · 2 calls: Inspect the workspace.** Read protected server and workspace information after authorization. 2. **Document · 3 calls: Create, retry, read.** The retry returns the same document at revision 1. Read back its saved content. 3. **Task · 5 calls: Save and verify state.** Create, 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. *Summary of the recorded 11 September 2026 check. It covers document and task operations; memory across sessions needs a separate evaluation.* 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. ## The connection included an authorization boundary MCP provides a way for an AI application to call tools exposed by another service. Space’s connection also requires authorization for the selected workspace. A client’s transport and authorization support matter; the protocol name alone is not evidence that every client will connect successfully. In this check, Codex used an OAuth connection with write access approved through the browser. We initially encountered a configuration error in the sign-in redirect URL. After correcting it, a fresh authorization request produced the expected redirect and the protected calls succeeded. This is why our public connection guide tells people to use the exact command and endpoint advertised by their installation. The marketing domain is not a public MCP endpoint, and copying a development URL from a build note would not create access. ## 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. ## Further reading - [How agent connections work in Space](https://getspace.sh/docs/connect) - [The Model Context Protocol](https://modelcontextprotocol.io/) - [How memory works in Space](https://getspace.sh/docs/how-memory-works) - [What to save before ending an AI coding session](https://getspace.sh/articles/ai-agent-session-handoff)