[Feature] Import / continue a chat.z.ai session inside ZCode by pasting its URL (cross-surface conversation continuity)

Summary

Allow users to load / import a chat.z.ai conversation session into ZCode by pasting the chat.z.ai session URL into ZCode, and then continue the work on their local project from within ZCode — preserving the full chat history, context, file references, and tool state from the original web session.

Today, chat.z.ai (web) and ZCode (desktop / CLI) are effectively two separate conversation silos. A user who starts a debugging session in chat.z.ai, then realizes they need to actually edit files, run commands, or apply diffs on their local project, has no clean way to bridge the work. They must either: (a) manually copy the relevant context out of chat.z.ai and re-paste it into a new ZCode conversation, losing tool state and conversation continuity; or (b) keep chat.z.ai open in one window and ZCode in another, copy-pasting each turn back and forth — which is fragile, slow, and breaks the agent's mental model.

This feature proposes: paste a chat.z.ai session URL into ZCode → ZCode fetches that session's full history + tool state → conversation resumes inside ZCode with the local project's files, terminal, and MCP tools now accessible.

Current Behavior

• chat.z.ai conversations live on Z.AI's servers, keyed by a session ID embedded in the URL (e.g. https://chat.z.ai/c/<session-id> or similar).
• ZCode conversations live locally (or in the user's ZCode workspace), with their own session ID space.
• There is no shared session layer between the two surfaces:
  • No way to "open this chat.z.ai conversation in ZCode."
  • No way to "continue this ZCode conversation in chat.z.ai" (the reverse direction — out of scope for this issue, but symmetric).
• A user who has done 30 minutes of triage in chat.z.ai — pasted stack traces, shared error context, refined the problem statement — has no way to carry that work into ZCode where the actual fix has to happen.
• Workarounds:
  1. Copy-paste the last N messages into a new ZCode conversation. Loses: file attachments, tool outputs, the model that produced each reply, and the implicit "we already established X" structure of a real conversation.
  2. Restart from scratch in ZCode. Wastes the chat.z.ai session entirely.
  3. Use chat.z.ai with a code interpreter / sandbox instead of ZCode. Loses: local file access, local terminal, MCP tools, git, the user's actual project.
• None of these are good. The user has to pick between "context-rich but execution-poor" (chat.z.ai) and "execution-rich but context-poor" (ZCode).

Desired Behavior

1. "Import session from URL" entry point in ZCode.
   • In the ZCode conversation list / new-chat dropdown, add an option: "Import from chat.z.ai…" (or a slash command like /import https://chat.z.ai/c/<session-id>).
   • User pastes the chat.z.ai session URL.
   • ZCode calls the Z.AI backend to fetch the session's full message history, attachments, tool calls, and the model used per turn.
2. Faithful reconstruction.
   • The imported conversation appears in ZCode's conversation list with a clear "imported from chat.z.ai" badge and the original session URL for reference.
   • Each message preserves: role, content, attachments, tool calls / tool results, and the model that generated each assistant turn.
   • User messages and tool outputs are rendered in ZCode's native UI; assistant messages render with a header showing "Generated by GLM-4.6 (via chat.z.ai)" or similar.
3. Seamless continuation.
   • The user can immediately send a new message in ZCode, and ZCode's agent picks up the imported context as if the conversation had been happening in ZCode all along.
   • All ZCode-side capabilities become available: read/write local project files, run terminal commands, invoke MCP tools, call sub-agents, apply diffs.
   • The agent has full visibility into the imported history — no need for the user to re-explain anything.
4. Attachment handling.
   • Files shared in the chat.z.ai session (images, logs, code snippets) are downloaded into a .zcode/imports/<session-id>/ folder inside the current workspace, so the agent can reference them by local path.
   • If the chat.z.ai session referenced external URLs (e.g. a GitHub repo, a doc), ZCode preserves them as-is.
5. Auth / ownership check.
   • The import only succeeds if the chat.z.ai session belongs to the same Z.AI account that's logged into ZCode. (Prevents importing other people's sessions.)
   • If the session belongs to a different account, the error message is explicit: "This chat.z.ai session belongs to a different account. Log in with the owning account to import."
6. Optional: reverse direction (out of scope, mentioned for symmetry).
   • A "Continue in chat.z.ai" action in ZCode would push the local conversation up to chat.z.ai and open it in the browser. Useful when the user wants to share the conversation with a colleague or continue on a different machine. Suggest deferring to a follow-up issue.

Why this matters

• Eliminates the "two surfaces" tax. Today, the user's choice of surface (web vs. desktop) at the start of a task locks them in for the entire task. With import, the user can start in chat.z.ai for fast triage / quick questions, then move to ZCode for execution — without losing anything.
• Matches how developers actually work. Real debugging sessions cross surface boundaries constantly: a quick question on the phone via chat.z.ai, then finish the fix on the laptop in ZCode. The current model forces the user to commit to one surface upfront.
• Increases ZCode stickiness. Every import is a moment where ZCode becomes the execution surface of record — chat.z.ai is the entry point, ZCode is where the work gets done. That's the right product positioning for Z.AI's coding plan.
• Reduces duplicate / wasted work. Today, users re-paste context, re-run expensive model calls, and re-attach files. Import eliminates all of that — saving tokens, time, and frustration.
• Competitive parity. GitHub Copilot Chat (web) and Copilot in VS Code already share a conversation surface in this way. Z.AI's split is a meaningful gap.

Use Cases

• Quick triage → real fix. User notices a bug on their phone, opens chat.z.ai, pastes the error, gets a 3-message diagnosis. Back at their laptop, they paste the chat.z.ai URL into ZCode, the imported context loads, and they immediately say "OK, apply the fix to src/auth.rs" — ZCode's agent does the rest locally.
• Long research session → execution. A user spends 45 minutes in chat.z.ai exploring a library's API, comparing approaches, pasting doc snippets. Now they want to actually write the code. They import the session into ZCode and the agent has the full exploration history to draw on — no re-explaining.
• Cross-machine handoff. A user starts a conversation on a personal laptop in chat.z.ai, then wants to continue it on a work machine where the project lives. Import by URL is instant; no need to set up sync or share anything.
• Pair programming / collaboration. One teammate does the diagnosis in chat.z.ai, shares the URL with a second teammate, who imports it into their ZCode to apply the actual code changes against their local checkout.

Auth / Privacy / Security Notes

• Same-account only. Import requires that the chat.z.ai session's owner matches the ZCode-logged-in account. OAuth tokens are already shared between the two surfaces via the Z.AI account — no new auth model needed.
• No public sharing. A chat.z.ai URL is not a share link by default; importing someone else's URL just fails. (If Z.AI later adds explicit "share this conversation" links, those could be imported by anyone with the link — but that's a separate feature.)
• Local artifact storage. Imported attachments land under .zcode/imports/<session-id>/ in the current workspace. Users who don't want these in their repo should add that path to .gitignore (ZCode can offer to do this automatically on first import).
• Audit trail. Each imported message keeps its original timestamp and a "via chat.z.ai" provenance marker, so it's always clear which messages came from where.

Implementation Notes

• Backend: session fetch endpoint. Z.AI already has the chat.z.ai session data in its database — a new authenticated endpoint (e.g. GET /api/chat/sessions/<id>) returning the full message tree + attachments is the main backend work. The data almost certainly already exists for the chat.z.ai web UI to render it; this just exposes it to ZCode.
• Frontend: ZCode import flow. A "paste URL → fetch → render" wizard. The hard part is rendering chat.z.ai-specific message types (e.g. canvas artifacts, web search results) in ZCode's UI — for v1, unknown message types can be rendered as a fallback "see original" block linking back to the chat.z.ai URL.
• Quota. Importing itself should be free (it's just a read). Subsequent turns in ZCode bill against the user's Coding Plan quota as normal — no double-billing.
• Versioning. If chat.z.ai adds new message types later, ZCode's importer should degrade gracefully (render unknown types as a fallback block) rather than failing the entire import.

Related

• #122 — chat.z.ai: switch model mid-conversation. Once import lands, the imported session preserves per-message model info, which makes #122 more valuable (you can see which model produced each turn of the original chat.z.ai session).
• #127 — Use Coding Plan tokens inside chat.z.ai. Strongly synergistic: #127 unifies billing across the two surfaces; this issue (#129) unifies conversations. Together they make chat.z.ai and ZCode feel like one product instead of two.
• #119 — When opening a file in ZCode, let me choose which EXISTING conversation to send it to. Same theme: ZCode should treat conversations as a first-class, reusable, addressable object — not a throwaway per-task scratchpad.

Regards,
Roman
http://www.rommark.dev
VIbe Coders Telegram Channel: https://t.me/VibeCodePrompterSystem

The payload identifies no repository files, tests, or implementation entry points; first map ZCode's conversation-list/new-chat UI and the authenticated chat.z.ai session API before estimating the work. Done would require importing an owned session with its history and attachments, rendering it in ZCode, and allowing local-project continuation with clear failure handling.