Driving pi with computer using ChatGPT sessions

retained text

Driving pi with computer using ChatGPT sessions
How I use ChatGPT tasks to organize persistent Pi sessions, connect MCP tools, bridge gaps with computer use, and deliver work without losing context.
For the init() recaps, I used ChatGPT tasks as folders for the work: one task to coordinate the series, then one per article where I could give feedback. Under each article task was a persistent Pi session connected to our Blog Bot through MCP. Astra coordinated the work from ChatGPT while Pi held the writing context, tools, and exact draft identity underneath it.
I like this setup because the top level feels familiar. It is roughly the same organization I get from named terminal tabs, except a new task can use my existing tooling to start or resume the session that owns the work. The initial task coordinated sources and drafting; the separate article tasks came later for editing. One active writer owned each article.
The hierarchy I actually use
A ChatGPT task is one concern or bucket of work. It might coordinate a series, own one article, or track an integration repair. I do not treat it as a security boundary or proof that the work is finished.
Pi sits below that task layer. Pi is an extensible agent harness with interactive, print/JSON, RPC, and TypeScript SDK modes. Its sessions retain the conversation and tool results, while extensions and skills let me reuse capabilities across projects.
Astra and Pi do different jobs here. Astra is the model coordinating my ChatGPT task. Pi is the persistent harness doing the assigned work. Pi can use a different model and provider from Astra. More important, my connectors, shared instructions, model routing, and custom business tools remain available independently of the outer task UI. I can also open the Pi session directly.
For the init() series, the coordinator collected transcript captures, article briefs, attribution corrections, a source registry, and per-article facts. It kept the planned agenda separate from what the transcripts supported. The ten writing sessions each pointed to one Blog Bot draft, and the later editing tasks resumed those exact sessions instead of starting over.
Connect Pi to your tools
Recent upstream Pi versions include MCP support. My installed workflow uses version 2.32.1 of the Pi MCP Adapter, so that is the setup I will show here. The adapter discovers tools on demand, which keeps a large tool catalog out of the initial prompt.
Install the adapter, then restart Pi:
pi install npm:pi-mcp-adapter
Add your server to the project's .mcp.json, or merge it into the shared MCP configuration you already use:
{
  "mcpServers": {
    "blogbot": {
      "url": "https://mcp.example.com/blog",
      "auth": "oauth"
    }
  }
}
That endpoint is illustrative and will not work as written. Blog Bot is an internal WorkOS service, not a public product readers can sign up for. Substitute the MCP server for your CMS, issue tracker, or other destination. The adapter documents installation, .mcp.json discovery, and OAuth authentication.
For an OAuth server, authenticate and then perform a read-only identity or tool-discovery check before giving the session a writing assignment:
/mcp-auth blogbot
The login belongs to the Pi environment. I pass draft IDs and source paths through task handoffs, never credentials.
I keep connector setup separate from the task brief. The MCP configuration answers how Pi reaches the service and authenticates. The brief says what this session may do, which sources it should use, and where it must stop. That lets a new article task reuse a working connector without copying setup details or secrets into every prompt. MCP supplies the external tools; the invoking environment still decides which calls require approval.
Start one bounded Pi session
After Pi is installed and logged in to the provider I want, I create a named session in the project directory. The current Pi documentation is at pi.dev.
cd /path/to/project
pi --session-dir /path/to/pi-sessions/article-05 \
  --name "article-05-writer" \
  @briefs/article-05.md \
  "Draft the assigned article, save it through the CMS tool, and stop before staging."
Pi creates a session filename containing a timestamp and ID. Retain the exact path it produced. A later edit should resume that file rather than continue whichever session happened to run last:
pi --session /path/to/pi-sessions/article-05/2026-10-09T12-00-00-000Z_SESSION-ID.jsonl
A programmatic parent can run the same assignment in print mode:
pi --print --mode json \
  --session-dir /path/to/pi-sessions/article-05 \
  --name "article-05-writer" \
  @briefs/article-05.md \
  "Create the draft and return its saved identity."
JSON mode emits session, message, and tool events, so the caller must parse a stream rather than expect one ready-made result object. RPC is available when a parent application needs a live conversation. These paths assume the outer session has terminal tools. If it only has access to a terminal UI, computer use can operate that UI instead. Not every ChatGPT mode or account exposes terminal or computer tools, so this tutorial assumes they are enabled.
I configure Pi's provider and model separately. Those do not need to match Astra. For the recap project, some writer sessions used our cloudflare-ai-gateway/claude-opus-5-5 route with xhigh thinking. That is one concrete configuration from this job, not required setup.
Give the outer task a useful prompt
The outer task needs an outcome, selected sources, and exact durable identities. It does not need every raw company document. Here is a compact prompt to adapt:
Start or resume the named Pi session for this article. Give it the selected brief
and source files plus the exact existing CMS draft key. It must read the live draft
and version before editing, preserve newer human changes, save through the CMS tool,
read the result back, run the editorial checks, and return the draft URL plus one next
action. Use the signed-in UI only when a required operation is unavailable through the
tool. Stop before staging or publication so I can review the first run.
My handoff also records the exact Pi session file, current artifact version, owner, and completion criteria. A compact machine-readable record might look like this:
{
  "task": "edit-article-05",
  "piSession": "/path/to/pi-sessions/article-05/2026-10-09T12-00-00-000Z_SESSION-ID.jsonl",
  "sources": ["briefs/article-05.md", "sources/registry.json"],
  "artifact": {
    "system": "cms",
    "key": "draft:example-05",
    "version": 7
  },
  "next": "read the live draft before editing"
}
Those values are illustrative. The important part is retaining both session and artifact identity. If another editor changes the draft, the writer fetches the new version and reapplies its edit. If a write times out, it reads the destination to determine whether the original action committed before trying anything else.
Make the save verifiable
For Blog Bot, the writer first discovers the live tool schema and reads the editorial rules. It creates one draft with a stable request ID, or reads the current version before changing an existing draft. The save includes the article body, CMS metadata, and a source-backed fact ledger.
Then it reads the saved object back and runs the same content checks used later in the publication workflow. The handoff records the draft key, editor URL, version, and next action. My local workbench can submit creation and versioned-edit arguments from a JSON file, retain the receipts, and perform that readback. Staging and publishing remain separate operations.
This is deliberate. A successful mutation response only tells me that the service accepted a request. It does not tell me that the final destination contains the intended body, byline, links, or images. After a consequential edit I inspect the saved object. After publication I inspect the public page.
Choose the shortest capable path
I use a direct tool call for a small structured operation such as fetching one draft or changing one known field. If the parent already knows the tool, object, and desired change, another agent loop usually adds delay without improving the result.
I use Pi when the work spans sources and revisions, because the persistent session retains decisions, previous checks, and user feedback. It earns its keep when a later edit depends on why an earlier sentence changed, which source boundaries still apply, or which version the writer last inspected. Independent work gets its own session and checkout rather than being folded into an unrelated writer.
Computer use covers the remaining gap. OpenAI describes computer use as a way for a model to operate browser and desktop interfaces through a harness. In practice, I reach for it when a connector is missing, broken, or unable to express a required UI operation. The UI session uses the permissions of the signed-in account, so I keep the intended account and scope consistent when moving between tool and UI.
My blunt prediction is that if you do not build an API, people will have a computer-using model operate your UI. A missing API does not keep agents out. It changes the interface they use and usually makes the work slower and harder to verify.
The image import that forced the fallback
The published init() 2026 recap gave me a concrete example. Blog Bot tried to import an obsolete default cover URL. The origin returned an XML access-denied response, Webflow rejected the image, and the bot retained an unresolved dispatch guard.
I had Astra use the existing authenticated Webflow UI to inspect the CMS item, insert the approved photos and screenshots, set a working cover, save, and reload. Once I approved publication, the session published through that UI. Four article images loaded, and the social metadata referenced the approved venue photo.
Delivering the article and repairing the integration were separate jobs. A dedicated Pi session investigated the bug in an isolated checkout, removed the dead fallback reference, and improved rejection and unknown-outcome handling. It produced a draft pull request with passing local tests and a build, but the fix was not deployed at handoff.
That distinction is useful beyond publishing. A successful tool response does not prove that the destination is correct, and a completed UI fallback does not prove the connector is repaired. After a consequential edit, I read the saved object and inspect the destination. Unknown writes get reconciled before retrying.
Account for the waiting
Astra can be quite slow. The delay compounds when a parent asks a Pi session to act, Pi calls a remote tool, the parent checks the result, and a UI fallback adds another round trip. Actual elapsed time and my supervision burden are different costs. A longer unattended run may demand less attention than a faster loop that repeatedly stops for input.
I reduce the serial work by giving Pi a larger bounded assignment: read the selected sources, draft, save, read back, run checks, and stop at a review boundary. That is coarse enough to produce something reviewable without asking the parent to shuttle every paragraph between systems.
Independent reads can run separately, while simple lookups stay direct. I also avoid nesting Pi underneath the parent for operations the parent can safely perform in one tool call. Persistent sessions do not make the model faster, but they keep me from rebuilding the working set for every edit.
This post followed the same pattern it describes. A dedicated Pi session drafted and saved it through Blog Bot, while the outer task reviewed the writing and prepared the images.
The durable handoff is the part I care about most. Keep the exact Pi session path and the exact saved artifact key and version together. Then the next task can resume the work without guessing which conversation knew the context or which object it is about to change.

document fetched 2026-10-24 10:07