Jonas Notes

Bastion - Cursor as Primary Runtime Plan

10 min read

Bastion - Cursor as Primary Runtime Plan

Objective

Use Bastion as the first experimental OpenClaw deployment where the assistant no longer relies on the current Codex / ChatGPT subscription-backed main runtime.

Instead, Bastion should be set up so that:

  • OpenClaw remains the gateway, routing, session, and orchestration layer
  • Cursor becomes the primary conversational / execution runtime path
  • the deployment is isolated under a new dedicated user instead of opc
  • the result can later inform whether this should become:
    • an ACP-first production setup, or
    • a future first-class Cursor provider integration inside OpenClaw

Desired Outcome

Functional goal

When Jonas sends a message to the Bastion-backed assistant, the normal hot path should be:

flowchart LR
    U[Jonas on Telegram] --> G[OpenClaw on Bastion]
    G --> A[ACP / Cursor runtime]
    A --> G
    G --> U

Non-goals for this phase

This phase is not trying to:

  • build a full first-class cursor model provider in OpenClaw
  • modify openclaw onboard yet
  • replace all existing Pathfinder production infrastructure immediately
  • design the final polished long-term UX

This phase is about validating:

Can Cursor act as the primary runtime behind OpenClaw well enough that Codex is no longer required in normal usage?

Why Bastion

Bastion is the right target for the first implementation because it provides:

  • a separate machine in the same Tailscale network
  • a safe environment for changing runtime architecture
  • isolation from the current working Pathfinder deployment
  • a realistic environment for testing remote operation, persistence, and service management

Deployment Strategy

High-level architecture

flowchart TD
    subgraph User_Side[User Side]
        T[Telegram conversation]
    end

    subgraph Bastion[Bastion Host]
        O[OpenClaw Gateway]
        R[Routing / Sessions / Memory / Tools]
        P[ACP control plane]
        C[Cursor runtime session]
        S[systemd services]
        W[Dedicated workspace + agent state]
    end

    T --> O
    O --> R
    R --> P
    P --> C
    C --> P
    P --> O
    O --> T

    O --> S
    O --> W
    P --> W
    C --> W

Core Design Decision

Near-term approach: ACP-first, not provider-first

The initial Bastion implementation should treat Cursor as:

  • a primary ACP runtime target
  • not yet a first-class OpenClaw model provider

Why

A full first-class provider would require:

  • provider abstraction work
  • onboarding changes
  • auth/token lifecycle support
  • model discovery/catalog support
  • product-level provider UX

That is a larger product feature.

The ACP-first route is a better first milestone because it directly answers the real question:

Can OpenClaw stop depending on Codex and route normal usage through Cursor instead?

User and Host Layout

New dedicated user

Do not use opc as the long-term service owner.

Create a dedicated system user, for example:

  • claw
  • or openclaw

Recommended choice for consistency:

  • claw

Why this matters

flowchart LR
    A[Use opc] --> B[Fastest to start]
    A --> C[Mixed ownership]
    A --> D[Shared admin environment]
    A --> E[Messier long-term operations]

    F[Use dedicated claw user] --> G[Clean service ownership]
    F --> H[Cleaner secrets boundary]
    F --> I[Predictable state paths]
    F --> J[Safer long-term maintenance]

Expected layout

/home/claw/
  .openclaw/
    openclaw.json
    workspace/
    agents/
    logs/

Optional future refinement:

  • separate repo checkout for OpenClaw source work
  • separate workspace or profile for experimental agents

Bastion Implementation Phases

Phase 0 - Host preparation

Goal

Prepare Bastion as a clean service host for OpenClaw + Cursor runtime work.

Tasks

  • Create a new user: claw
  • Ensure SSH access works for that user
  • Ensure the user can operate within Tailscale-reachable workflows
  • Verify system dependencies:
    • Node / npm / bun / pnpm as needed
    • git
    • systemd user or system service support
    • Tailscale installed and connected
  • Decide whether OpenClaw should run as:
    • user service under claw, or
    • system-level service owned by claw

Recommendation

Use a systemd service owned by claw unless there is a strong reason to use user lingering.

Phase 1 - Base OpenClaw installation on Bastion

Goal

Install a fresh OpenClaw instance under the claw user without importing the production runtime assumptions from Pathfinder.

Tasks

  • Install OpenClaw on Bastion
  • Initialize state under /home/claw/.openclaw
  • Configure Tailscale exposure if needed
  • Bring up the OpenClaw gateway locally first
  • Confirm the dashboard and local status work

Deliverables

  • Bastion OpenClaw service starts successfully
  • Control UI reachable over approved path
  • clean workspace exists under the new user

Phase 2 - ACP runtime capability baseline

Goal

Validate that Bastion can host ACP-based runtimes cleanly before involving Telegram routing.

Tasks

  • Install ACP backend/plugin support required by OpenClaw
  • verify ACP tooling is present and healthy
  • confirm /acp doctor-equivalent diagnostics are healthy
  • validate that OpenClaw can create, manage, and close ACP sessions on Bastion

Questions to answer in this phase

  • Is the current OpenClaw ACP backend stable enough on Bastion?
  • Are there any session-init or session-binding issues?
  • Does Bastion have the right runtime dependencies for long-lived ACP sessions?

Exit criteria

OpenClaw on Bastion can successfully:

  • initialize ACP
  • spawn a persistent ACP session
  • steer it
  • inspect status
  • close it cleanly

Phase 3 - Cursor runtime integration

Goal

Make Cursor usable as a real runtime target on Bastion.

Two possibilities

Path A - Cursor already usable through ACP with small glue

If Cursor runtime support already exists but is undocumented/incomplete:

  • configure allowed harness ids
  • confirm the right spawn target name
  • verify runtime command / session behavior

Path B - Cursor not yet first-class in ACP

If Cursor is not currently exposed as a normal ACP target, then the work becomes:

  • add Cursor as a harness alias / target
  • ensure the backend knows how to launch and manage it
  • document session lifecycle behavior

Tasks

  • Install/auth Cursor on Bastion
  • verify headless/non-interactive operation is acceptable
  • identify the exact runtime invocation pattern needed
  • test persistence semantics:
    • new session
    • follow-up turns
    • cancellation
    • close
  • confirm whether OpenClaw can treat Cursor as:
    • a named ACP harness target
    • and a default ACP agent target

Exit criteria

Bastion can support a stable persistent Cursor-backed ACP session.

Phase 4 - Make Cursor the default runtime path

Goal

Shift Bastion’s normal assistant flow away from Codex and onto Cursor.

Conceptual configuration target

flowchart LR
    M[Incoming Telegram DM] --> O[OpenClaw Bastion]
    O --> B[Bound or default ACP session]
    B --> C[Cursor runtime]
    C --> O
    O --> R[Reply to Telegram]

Desired config direction

At a high level, Bastion should move toward:

  • ACP enabled
  • Cursor allowed as an ACP target
  • Cursor selected as the default ACP runtime target
  • normal conversation flow routed into Cursor-backed sessions
  • Codex removed from the default hot path

Important note

There are two possible ways to implement this behavior:

Option 1 - Bound conversation model

Bind the Telegram DM or test conversation directly to a persistent Cursor ACP session.

Pros

  • easiest to test first
  • explicit and observable
  • least ambiguous routing behavior

Cons

  • may feel a bit more session-bound / runtime-bound
  • reset/new semantics may need more care

Option 2 - Fully default runtime model

Configure Bastion so the default assistant path effectively runs through Cursor-backed ACP behavior automatically.

Pros

  • closer to the final intended UX
  • more seamless if it works

Cons

  • depends on more OpenClaw runtime assumptions being compatible
  • may expose rough edges more quickly

Recommendation

Start with Option 1, then evaluate whether it should evolve into Option 2.

Phase 5 - Telegram wiring and live-user validation

Goal

Attach a real messaging path and evaluate actual daily UX.

Tasks

  • provision a dedicated Telegram bot/account for Bastion if needed
  • route Jonas-only traffic to the Bastion agent
  • test:
    • first message behavior
    • multi-turn continuity
    • /new
    • /reset
    • thread/session continuity
    • failure handling
    • restarts and persistence

Validation questions

  • Does it feel like one assistant, or like a wrapper around Cursor?
  • Is the ACP session state understandable and recoverable?
  • Are resets intuitive?
  • Are failure modes acceptable?
  • Is Codex truly out of the hot path?

UX Comparison Targets

What “good enough” should feel like

The user experience should ideally feel like:

  • Jonas messages the Bastion assistant normally
  • the assistant responds normally
  • no special worker choreography is required for every turn
  • Cursor is mostly invisible as infrastructure
  • session continuity is stable enough that it does not feel fragile

Acceptable first-version compromise

Even if the experience is slightly more ACP/session-oriented than a normal model-provider setup, it is acceptable if:

  • it reliably avoids Codex usage
  • it is understandable
  • it is stable enough for real conversations

Risks and Unknowns

1. ACP bridge/runtime rough edges

There may still be rough edges around:

  • session initialization
  • persistent bindings
  • restarts
  • metadata reconciliation
  • Telegram conversation binding semantics

2. Cursor CLI/runtime behavior

Unknowns include:

  • auth persistence
  • stability of non-interactive runtime use
  • whether session naming/persistence semantics fit OpenClaw expectations well
  • whether runtime output format is robust enough for OpenClaw delivery

3. UX ambiguity

A runtime-driven architecture may feel subtly different from a first-class provider-driven architecture.

The Bastion pilot needs to evaluate whether this difference is acceptable in daily use.

4. Future migration cost

If the ACP-first approach works but feels rough, future product work may still be needed to build:

  • first-class Cursor onboarding
  • a native provider model
  • cleaner runtime defaults

Rollback Plan

If Bastion ACP-first Cursor integration is not good enough:

Rollback options

  1. Keep Bastion as a research/sandbox instance only
  2. continue using Pathfinder production on Codex temporarily
  3. use Cursor only as delegated ACP worker, not primary runtime
  4. revisit a proper first-class Cursor provider implementation later

Rollback should be easy because:

  • Bastion is isolated
  • new user is dedicated
  • no production cutover happens during the pilot

Success Criteria

This Bastion experiment is successful if all of the following are true:

  • a dedicated claw user runs OpenClaw cleanly on Bastion
  • ACP sessions are stable
  • Cursor can function as the primary runtime target
  • a real conversation can be routed through Cursor-backed execution
  • normal usage no longer depends on Codex in the hot path
  • the resulting UX is acceptable enough to justify deeper product work

Concrete Execution Checklist

Host setup

  • SSH into Bastion
  • create claw user
  • set up SSH access for claw
  • verify Tailscale connectivity as needed
  • install runtime dependencies

OpenClaw baseline

  • install OpenClaw
  • initialize fresh state under /home/claw/.openclaw
  • verify openclaw status
  • bring up gateway service

ACP baseline

  • install/enable ACP backend/plugin
  • verify ACP diagnostics
  • create and manage a test ACP session

Cursor runtime

  • install/auth Cursor on Bastion
  • verify session-based invocation works
  • identify required harness alias / runtime target
  • confirm persistent Cursor-backed session lifecycle

Routing

  • configure Bastion so a test conversation can route into Cursor-backed ACP
  • verify Telegram interaction path
  • test /new and /reset
  • confirm no normal Codex hot-path usage

Evaluation

  • evaluate UX quality
  • document rough edges
  • decide: continue ACP-first or plan first-class provider work

Future Follow-up Notes

Possible follow-up notes to create after implementation starts:

  • AI/OpenClaw Cursor Migration/Bastion - Host Bootstrap Checklist.md
  • AI/OpenClaw Cursor Migration/Cursor ACP Runtime Notes.md
  • AI/OpenClaw Cursor Migration/Open Questions - Cursor as Provider vs ACP.md
  • AI/OpenClaw Cursor Migration/Bastion - Execution Log.md

One-Paragraph Summary

The Bastion plan is to stand up a clean OpenClaw deployment under a dedicated claw user and make Cursor the primary runtime path through ACP rather than through a native model-provider integration. This is the lowest-risk way to validate the real product question—whether OpenClaw can stop depending on Codex for normal usage—without first building a full first-class Cursor onboarding/provider feature. Bastion acts as the isolated proving ground; if the UX and reliability are good enough, the experiment can later inform either a broader rollout or a deeper native Cursor integration inside OpenClaw.

Backlinks