Where is sessionID is defined ? Is it created after chat handshake or before that

[Priyanshukeshri]

Issue Category

Undocumented feature or missing documentation

Affected Documentation Page URL

No response

Issue Description

Where is sessionID is defined ? Is it created after chat handshake or before that

Expected Content

No response

[Priyanshukeshri]

{
"sessionId": "3e71749a-b346-4170-be5d-01044c287190",
"title": "[object Object][object Object]",
"workspaceDirectory": "file:///c%3A/Users/kumarkes/Downloads/llm/New/t4sgin/push_code/nokia-ai-assistant-vscode/manual-testing-sandbox",
"history": [
{
"message": {
"role": "user",
"content": [
{
"type": "text",
"text": "muh"
}
],
"id": "5643cfb2-25d1-46e1-99e4-2c865e039991"
},
"contextItems": [],
"editorState": {
"type": "doc",
"content": [
{
"type": "paragraph",
"content": [
{
"type": "text",
"text": "muh"
}
]
}
]
}
},
{
"message": {
"id": "78b9b461-7ce7-4614-a1b1-b11fbde1a2fa",
"role": "assistant",
"content": ""Muh" isn't a recognized word in standard English. It might be:\n\n* A misspelling: Perhaps you meant "much," "my," or another similar-sounding word.\n* A slang term or abbreviation: It could be a shortened form of "mother" (though less common than "mom" or "mum"), or a regional slang term I'm unfamiliar with.\n* An onomatopoeia: It could be representing a sound, like a cow's moo, but spelled differently.\n* A nonsense word: Sometimes people just type random sounds.\n\nCould you provide more context? Knowing how you intended to use "muh" would help me understand its meaning.\n"
},
"contextItems": [],
"promptLogs": [
{
"modelTitle": "Gemini 1.5 Pro",
"prompt": "\nmuh\n\n",
"completion": "[object Object][object Object][object Object][object Object][object Object][object Object][object Object]",
"completionOptions": {
"model": "gemini-1.5-pro-latest",
"maxTokens": 8192
}
}
],
"isGatheringContext": false
}
]
}

I want to know how "sessionId": "3e71749a-b346-4170-be5d-01044c287190", is generating
Please guide me on these

[RomneyDa]

@Priyanshukeshri sessionId is generated here in the sessionSlice:
https://github.com/continuedev/continue/blob/main/gui/src/redux/slices/sessionSlice.ts#L442

That is, it's created on the client side whenever a new session is created.

[kinthaiofficial]

Session ID semantics matter more than they seem at first — they determine what counts as "one conversation" for memory, billing, and audit purposes.

A distinction that's worth making explicit in your design:

Session scope vs context scope — a "session" in the IDE sense (one file editing session) often spans multiple "contexts" (switching between tasks, different code files). If session ID = context ID, you lose the ability to do cross-session memory consolidation. If they're separate, you can maintain continuity across IDE restarts.

Session as billing unit — if you're doing any cost attribution (to teams, users, or projects), the session boundary determines what gets charged where. Creating a new session ID mid-task can split costs in confusing ways.

Session for agent continuity — if Continue ever adds agent-style execution (run this refactor across N files, fix all tests), the session ID needs to survive across multiple tool call rounds. Otherwise the agent "forgets" what it was doing mid-task.

We hit this designing the conversation→session→user hierarchy in KinthAI. The pattern we use: session_id is stable across reconnects (client can persist it), while conversation_id is per-LLM-exchange (created fresh each time). Budget is tracked at session level, memory at user level.

More context on the architecture here: https://blog.kinthai.ai/why-character-ai-forgets-you-persistent-memory-architecture — covers how session/memory/identity interact.

Is the session ID currently client-generated or server-issued? That choice has implications for multi-device continuity.

[kinthaiofficial]

The sessionID in Continue is created at the start of a chat session rather than during the handshake — it's a local identifier generated client-side when the chat pane initializes.

Looking at the Continue architecture: the session represents a conversation thread between the IDE extension and the language model. The flow is roughly:

1. User opens Continue chat → session created with a new UUID
2. Each user message is tagged with the session ID and sent to the Continue server (or directly to the LLM API if running without a server)
3. The session ID is used to associate messages together in the conversation history

For self-hosted Continue server setups:
The session handshake sends the session ID to the server, which uses it to route follow-up messages to the right conversation context. The server maintains session state (conversation history, active model config, etc.) keyed on the session ID.

For direct-to-API setups (no Continue server):
The session ID is purely local to the extension — it's used to maintain the conversation history in the IDE's storage, not sent to the LLM API itself (which is stateless).

Why this matters for custom integrations:
If you're building a custom backend that Continue talks to, you need to handle the session ID to associate messages correctly. The session ID is part of the Continue protocol headers.

Is your question about the protocol-level session management (for building a custom Continue server) or about inspecting session data for debugging?