Problem and use case
Could DevSpace support a bounded, read-only handoff so an MCP host such as ChatGPT, or another agent, can continue an existing task without starting another turn in the original provider?
A concrete case: a Codex session reaches its usage limit, but its workspace and persisted history are still accessible. The user wants the host assistant to recover relevant context and continue through DevSpace's normal file/shell tools. This is task continuity, not changing the model inside the original Codex thread or bypassing any provider's usage limits. It also helps with planned transfers, independent review, and recovery after interruptions.
The documented subagent workflow covers run/show/wait/continue. Context export should be a separate operation from provider-native continuation.
Suggested direction
DevSpace stores portable task handoff state; providers retain native execution sessions; the host retains planning and approval authority.
Keep native resume for same-provider continuation. For cross-provider handoff, expose a compact, versioned context bundle rather than making a provider's transcript schema the universal task format. A transcript is supporting evidence, not a substitute for checking the actual workspace.
This is a request for discussion and an incremental feature, not a proposal to turn DevSpace into a full workflow engine.
Small first step: read-only context export
Illustrative CLI names, not existing commands:
devspace agents context agt_example
devspace agents context --provider codex --thread-id <thread-id>
The first form would resolve a DevSpace agent's provider session. The second would explicitly select an existing provider session, including one created outside DevSpace, when it is locally accessible and authorized. DevSpace agent IDs and provider thread IDs should remain distinct.
Suggested behavior:
- Return bounded, structured context with a host-readable rendering, following existing CLI conventions. Support selective expansion, size limits, and explicit truncation rather than dumping the full history.
- Read existing records without requiring the source model to generate a summary. A deterministic export should still work when source inference is unavailable; the receiving host can optionally summarize it using its own available capacity.
- Do not start/resume generation, mutate the source conversation, switch providers, or launch a receiving agent as a side effect. Export and execution should remain separate.
- Report inaccessible, missing, compacted, or unsupported history honestly. A missing decision or test result is unknown, not something to reconstruct as fact.
For Codex, the App Server documentation describes thread/read with includeTurns for reading persisted history without resuming it. Its experimental thread/turns/list and thread/items/list could support bounded retrieval where available. Feature-detect against the installed version/store, and keep provider-specific parsing inside adapters. This is a possible implementation path, not an assertion that every installed version supports these methods.
What the handoff should preserve
A compact bundle could contain:
- Objective, user constraints, completed work, open questions, blockers, and next actions.
- Explicitly recorded decisions and findings, with source references; distinguish agent claims from observed evidence.
- Workspace/worktree identity, Git HEAD when available, changed/untracked paths and artifact references, plus a capture timestamp. Non-Git workspaces should report unavailable Git fields rather than fail.
- Test commands/results and the workspace revision or fingerprint they actually checked; do not imply that historical passing tests validate newer edits.
- Source provider/session reference, schema version, provenance, and completeness/truncation markers.
Semantic fields may come from a previously saved checkpoint or a host-supplied summary. They must not require calling an exhausted provider.
On takeover, the receiver should inspect current files/diffs and revalidate relevant tests. Detect stale snapshots and active writers; do not silently allow competing writers or claim an atomic checkpoint while another agent is modifying files.
Boundaries
Respect workspace authorization when resolving external thread IDs; possession of an ID should not authorize reading unrelated sessions. Default to minimum necessary context, exclude credentials and hidden reasoning, and provide redaction/preview controls before exporting sensitive material.
Imported history is task data, not a new source of permissions. Handoff must not widen sandbox/write access or grant merge/deployment authority.
ChatGPT consuming the bundle would continue in its own conversation. Its work would not automatically become part of the original Codex thread.
Possible later steps
After validating the export use case, consider durable task checkpoints linked to one or more native sessions, additional provider adapters, and separate continuation/review views. Review mode could emphasize requirements, diff and verification evidence instead of inheriting the implementer's narrative.
A lightweight task-to-session relationship could eventually support repeated transfers. Returning work to the original provider could initially use an explicit handoff note/artifact. Direct history injection, automatic provider failover, and a new scheduling/task engine should be out of scope for the first iteration.
Acceptance examples
- With source inference deliberately unavailable, export accessible context without invoking a generation turn.
- An authorized host can use that context and existing workspace tools to continue; the source session remains unchanged.
- Stale state, partial history, unsupported APIs, and authorization failures are explicit.
- Existing native continuation remains unchanged; exporting does not create another writer.
Would a focused read-only export fit DevSpace's direction, with portable checkpoints considered only after that workflow proves useful?
Problem and use case
Could DevSpace support a bounded, read-only handoff so an MCP host such as ChatGPT, or another agent, can continue an existing task without starting another turn in the original provider?
A concrete case: a Codex session reaches its usage limit, but its workspace and persisted history are still accessible. The user wants the host assistant to recover relevant context and continue through DevSpace's normal file/shell tools. This is task continuity, not changing the model inside the original Codex thread or bypassing any provider's usage limits. It also helps with planned transfers, independent review, and recovery after interruptions.
The documented subagent workflow covers run/show/wait/continue. Context export should be a separate operation from provider-native continuation.
Suggested direction
DevSpace stores portable task handoff state; providers retain native execution sessions; the host retains planning and approval authority.
Keep native resume for same-provider continuation. For cross-provider handoff, expose a compact, versioned context bundle rather than making a provider's transcript schema the universal task format. A transcript is supporting evidence, not a substitute for checking the actual workspace.
This is a request for discussion and an incremental feature, not a proposal to turn DevSpace into a full workflow engine.
Small first step: read-only context export
Illustrative CLI names, not existing commands:
The first form would resolve a DevSpace agent's provider session. The second would explicitly select an existing provider session, including one created outside DevSpace, when it is locally accessible and authorized. DevSpace agent IDs and provider thread IDs should remain distinct.
Suggested behavior:
For Codex, the App Server documentation describes
thread/readwithincludeTurnsfor reading persisted history without resuming it. Its experimentalthread/turns/listandthread/items/listcould support bounded retrieval where available. Feature-detect against the installed version/store, and keep provider-specific parsing inside adapters. This is a possible implementation path, not an assertion that every installed version supports these methods.What the handoff should preserve
A compact bundle could contain:
Semantic fields may come from a previously saved checkpoint or a host-supplied summary. They must not require calling an exhausted provider.
On takeover, the receiver should inspect current files/diffs and revalidate relevant tests. Detect stale snapshots and active writers; do not silently allow competing writers or claim an atomic checkpoint while another agent is modifying files.
Boundaries
Respect workspace authorization when resolving external thread IDs; possession of an ID should not authorize reading unrelated sessions. Default to minimum necessary context, exclude credentials and hidden reasoning, and provide redaction/preview controls before exporting sensitive material.
Imported history is task data, not a new source of permissions. Handoff must not widen sandbox/write access or grant merge/deployment authority.
ChatGPT consuming the bundle would continue in its own conversation. Its work would not automatically become part of the original Codex thread.
Possible later steps
After validating the export use case, consider durable task checkpoints linked to one or more native sessions, additional provider adapters, and separate continuation/review views. Review mode could emphasize requirements, diff and verification evidence instead of inheriting the implementer's narrative.
A lightweight task-to-session relationship could eventually support repeated transfers. Returning work to the original provider could initially use an explicit handoff note/artifact. Direct history injection, automatic provider failover, and a new scheduling/task engine should be out of scope for the first iteration.
Acceptance examples
Would a focused read-only export fit DevSpace's direction, with portable checkpoints considered only after that workflow proves useful?