You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
GUI: New conversation auto-fills with previous conversation's first instruction (workspace prompt not cleared) #34393
When creating a new conversation in the OpenCode GUI (desktop app), the input dialog automatically fills with the first instruction (first user message) from the previous conversation.
Root Cause Analysis
After investigating the desktop app source code (version 1.17.11), the root cause has been identified:
The workspace-level prompt state is not cleared after a session is created from it.
Technical Details
OpenCode uses a persisted prompt state system with different scopes:
Session scope: session:{sessionID}:prompt ¡ª used when on a session page (has params.id)
Workspace scope: workspace:prompt ¡ª used when on a new session page (no params.id)
Draft scope: draft:{draftID}:prompt ¡ª used in the new layout draft flow
The bug flow (old layout, and potentially new layout in some cases):
User types in the new conversation input box ¡ú prompt saved under workspace:prompt
User submits the message ¡ú a session is created, submission.retarget() switches the prompt target from workspace scope to the new session scope
submission.clear() ¡ú only resets the session-scoped prompt, NOT the workspace-scoped prompt
User clicks "New Conversation" ¡ú workspace page loads ¡ú workspace:prompt is restored from disk with the old content ¡ú input box is pre-filled!
Key Code Locations (desktop app v1.17.11)
out/renderer/assets/main-D_cwiNV1.js:
createPromptSubmissionState (around line 112895) ¡ª clear() only resets the retargeted target, not the original workspace prompt
promptTarget() (around line 85207) ¡ª determines storage key based on scope
Persist.serverScoped() (around line 62940) ¡ª routes to serverWorkspace when no session ID
Submission flow (around line 113160-113180) ¡ª retarget() switches target but doesn't clear workspace scope
Thanks for the heads-up! I looked into #34069, and while the symptom is similar (new session inheriting previous content), there are a few differences worth noting:
Root cause analysis: This issue provides a detailed code-level root cause trace through createPromptSubmissionState ??promptTarget ??retarget ??clear, specifically identifying that workspace:prompt is the stale key that doesn't get reset after a session is created.
That said, the underlying mechanism is likely the same shared state management bug ??both TUI and GUI rely on the same createPromptSubmissionState / promptTarget / Persist plumbing. A fix in the shared prompt-clearing logic would probably resolve both.
Happy to close this as a duplicate of #34069 if the maintainers prefer, or keep it open as a companion tracking the GUI-specific manifestation. Either way, the root cause analysis here should help inform the fix. ??
The root cause analysis in the issue body is spot on — clearInput() resets the session-scoped prompt (after navigation changes the active scope), but the workspace-scoped prompt persists on disk and gets restored on the next "New Conversation" click.
The fix is to also explicitly reset the workspace-scoped prompt when a new session is created from it, by calling prompt.reset({ dir: base64Encode(projectDirectory) }) in clearInput().
Activity
github-actions commentedon Jun 29, 2026
This issue might be a duplicate of an existing issue. Please check:
ngleoi commentedon Jun 29, 2026
Thanks for the heads-up! I looked into #34069, and while the symptom is similar (new session inheriting previous content), there are a few differences worth noting:
/newcommand), while this issue is about the GUI desktop app (Electron, "New Conversation" button).createPromptSubmissionState??promptTarget??retarget??clear, specifically identifying thatworkspace:promptis the stale key that doesn't get reset after a session is created.That said, the underlying mechanism is likely the same shared state management bug ??both TUI and GUI rely on the same
createPromptSubmissionState/promptTarget/Persistplumbing. A fix in the shared prompt-clearing logic would probably resolve both.Happy to close this as a duplicate of #34069 if the maintainers prefer, or keep it open as a companion tracking the GUI-specific manifestation. Either way, the root cause analysis here should help inform the fix. ??
kagura-chen commentedon Jun 29, 2026
Hi 👋 I'd like to work on this.
The root cause analysis in the issue body is spot on —
clearInput()resets the session-scoped prompt (after navigation changes the active scope), but the workspace-scoped prompt persists on disk and gets restored on the next "New Conversation" click.The fix is to also explicitly reset the workspace-scoped prompt when a new session is created from it, by calling
prompt.reset({ dir: base64Encode(projectDirectory) })inclearInput().Happy to submit a PR.