[FEATURE]: Making sessions first-class unlocks cheap ChatGPT Projects #3187

Closed
opened 2026-02-16 17:39:02 -05:00 by yindo · 5 comments
Owner

Originally created by @mlanza on GitHub (Nov 28, 2025).

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

This is a terrific project. The CLI already shows a lot of thoughtful work. One area that feels ready for the next step is how sessions are handled. They’re useful, but they’re not yet treated as first-class artifacts — something worth managing, organizing, and bringing back into active work.

The CLI already supports exporting sessions. What’s missing is the other half: a way to bring them back in. Without import, exported sessions become static snapshots rather than living project material.

The reason this matters is how people actually ideate with AI. Work doesn’t happen in one sitting. You push an idea forward, park it, return days later, pick it up again, sometimes merge it with another thread, sometimes fork it. ChatGPT’s Projects embrace that reality beautifully — long-running arcs, evolving thought, incremental drafts.

The CLI could support that same workflow with one simple capability: treating sessions as durable, user-managed assets rather than something that lives quietly in a background pseudo-cache.

I keep my personal state in version control. A flat repo with folders mirrors how Projects feel in practice. If OpenCode could:

  • Allow pointing to multiple paths where session files might live
  • Treat those as valid sources for opening/continuing sessions
  • And show a small breadcrumb when opening one (so its origin is obvious)

…then the IDE-style workflow would click into place. Export → modify → version → import → continue. A smooth loop instead of a one-way door.

It doesn’t need to be elaborate. Even a minimal import mechanic and path list would unlock the whole pattern for people who use AI the way developers use notebooks, drafts, and branches: returning, revising, progressing.

Thanks again for sharing this project. It’s already impressive. Giving sessions a bit more weight — a bit more “first-class citizenship” — would make the CLI an even better companion for long-form, iterative thinking.

Originally created by @mlanza on GitHub (Nov 28, 2025). ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request This is a terrific project. The CLI already shows a lot of thoughtful work. One area that feels ready for the next step is how **sessions** are handled. They’re useful, but they’re not yet treated as *first-class artifacts* — something worth managing, organizing, and bringing back into active work. The CLI already supports **exporting** sessions. What’s missing is the other half: a way to bring them *back* in. Without import, exported sessions become static snapshots rather than living project material. The reason this matters is how people actually ideate with AI. Work doesn’t happen in one sitting. You push an idea forward, park it, return days later, pick it up again, sometimes merge it with another thread, sometimes fork it. ChatGPT’s Projects embrace that reality beautifully — long-running arcs, evolving thought, incremental drafts. The CLI could support that same workflow with one simple capability: treating sessions as durable, user-managed assets rather than something that lives quietly in a background pseudo-cache. I keep my personal state in version control. A flat repo with folders mirrors how Projects feel in practice. If OpenCode could: * Allow pointing to **multiple paths** where session files might live * Treat those as valid sources for opening/continuing sessions * And show a small breadcrumb when opening one (so its origin is obvious) …then the IDE-style workflow would click into place. Export → modify → version → import → continue. A smooth loop instead of a one-way door. It doesn’t need to be elaborate. Even a minimal import mechanic and path list would unlock the whole pattern for people who use AI the way developers use notebooks, drafts, and branches: returning, revising, progressing. Thanks again for sharing this project. It’s already impressive. Giving sessions a bit more weight — a bit more “first-class citizenship” — would make the CLI an even better companion for long-form, iterative thinking.
yindo added the discussion label 2026-02-16 17:39:02 -05:00
yindo closed this issue 2026-02-16 17:39:02 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Nov 28, 2025):

This issue might be a duplicate or closely related to existing feature requests. Please check:

  • #4317: Feature: generic /compact command, auto-compaction, and fork-aware conversations (addresses persistence and branching workflows)
  • #3000: [FEATURE] Clone / Branch a Session (requests session branching/cloning capability)
  • #1759: [Feature Request] Fork session (older request for forking sessions to explore multiple strategies)
  • #4457: [FEATURE]: Pin session (session management and organization)
  • #3227: [Feature] Reference another session with @ (cross-session references)

The core of your request—treating sessions as persistent, manageable artifacts that can be imported, exported, and organized across multiple paths—aligns with these existing discussions about session forking, branching, and workspace-level session management.

Feel free to ignore if your use case requires something more specific beyond what's covered in these issues.

@github-actions[bot] commented on GitHub (Nov 28, 2025): This issue might be a duplicate or closely related to existing feature requests. Please check: - #4317: Feature: generic /compact command, auto-compaction, and fork-aware conversations (addresses persistence and branching workflows) - #3000: [FEATURE] Clone / Branch a Session (requests session branching/cloning capability) - #1759: [Feature Request] Fork session (older request for forking sessions to explore multiple strategies) - #4457: [FEATURE]: Pin session (session management and organization) - #3227: [Feature] Reference another session with @ (cross-session references) The core of your request—treating sessions as persistent, manageable artifacts that can be imported, exported, and organized across multiple paths—aligns with these existing discussions about session forking, branching, and workspace-level session management. Feel free to ignore if your use case requires something more specific beyond what's covered in these issues.
Author
Owner

@mlanza commented on GitHub (Nov 28, 2025):

Although I'm not aware of any widely-adopted microformats for chat session data, I don't think it matters. You invent one you like. Start with a sufficient JSON structure. When formats eventually become standard, a format converter bridges the gap (e.g., PNG, JPG).

@mlanza commented on GitHub (Nov 28, 2025): Although I'm not aware of any widely-adopted microformats for chat session data, I don't think it matters. You invent one you like. Start with a sufficient JSON structure. When formats eventually become standard, a format converter bridges the gap (e.g., PNG, JPG).
Author
Owner

@rekram1-node commented on GitHub (Nov 29, 2025):

You can already import and export:

opencode export > session.json

opencode import session.json

@rekram1-node commented on GitHub (Nov 29, 2025): You can already import and export: opencode export > session.json opencode import session.json
Author
Owner

@mlanza commented on GitHub (Nov 29, 2025):

I appreciate the clarification — thank you.

That said, I think the workflow could use a small bump in ergonomics. The import/export commands living outside the TUI wasn’t something I expected. When I typed /export inside the TUI, it produced a .md file that couldn’t be imported with the command you mentioned. I realize now it was treated as a “transcript,” but that connection wasn’t obvious in the moment.

There’s also the issue of needing a session ID when exporting. That isn’t available inside the TUI, so I had to export the transcript just to discover the ID.

What I’m wrestling with is the workflow for saving multiple sessions to a local archive. The /session command already lists everything with readable, natural-language names, which makes it a much more intuitive touchpoint. As a middle ground, what about adding a ctrl+x export option there? It could save the session locally in JSON using the human-friendly session name. And having a TUI /import command would bring some balance to the existing TUI /export command. Right now there’s also a bit of mismatch between one being a transcript and the other expecting JSON.

My original suggestion wasn’t just about feasibility. I was aiming for something more ergonomic — something that gives users a way to manage sessions the way ChatGPT Projects could be managed and versioned. If the friction is too high, it's hard imagining it will be used in the way I’m suggesting.

@mlanza commented on GitHub (Nov 29, 2025): I appreciate the clarification — thank you. That said, I think the workflow could use a small bump in ergonomics. The import/export commands living outside the TUI wasn’t something I expected. When I typed `/export` inside the TUI, it produced a `.md` file that couldn’t be imported with the command you mentioned. I realize now it was treated as a “transcript,” but that connection wasn’t obvious in the moment. There’s also the issue of needing a session ID when exporting. That isn’t available inside the TUI, so I had to export the transcript just to discover the ID. What I’m wrestling with is the workflow for saving multiple sessions to a local archive. The `/session` command already lists everything with readable, natural-language names, which makes it a much more intuitive touchpoint. As a middle ground, what about adding a `ctrl+x export` option there? It could save the session locally in JSON using the human-friendly session name. And having a TUI `/import` command would bring some balance to the existing TUI `/export` command. Right now there’s also a bit of mismatch between one being a transcript and the other expecting JSON. My original suggestion wasn’t just about feasibility. I was aiming for something more ergonomic — something that gives users a way to manage sessions the way ChatGPT Projects could be managed and versioned. If the friction is too high, it's hard imagining it will be used in the way I’m suggesting.
Author
Owner

@mlanza commented on GitHub (Dec 2, 2025):

I take it back. We're good!

@mlanza commented on GitHub (Dec 2, 2025): I take it back. We're good!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3187