Repository navigation
Web UI does not list sessions and cannot start agent while TUI, attach and mobile work correctly #40809
Description
Description
Version
OpenCode v1.18.14
Environment
- Docker
- Coolify
- Cloudflare (HTTPS)
- Reverse proxy (Traefik)
- Basic Authentication enabled
- Persistent volumes configured
- Remote server
What works
- Web UI loads correctly.
- Authentication works.
/global/healthreturns:
{"healthy":true,"version":"1.18.14"}
opencode attach https://<server>works correctly.- TUI works correctly.
- Mobile clients can connect successfully.
- Sessions are persisted.
opencode session listshows existing sessions.
Problem
When opening the Web UI root (/):
- No existing sessions are displayed.
- There is no way to create a new session from the home page.
- The page always shows:
Nothing here yet
Create a session to get started
even though sessions already exist.
However, opening:
https://<server>/new
creates a new session.
The new session opens correctly, but sending a message never starts the agent.
The message is stored, but no assistant response is ever generated.
Opening the same session using opencode attach shows only the user messages.
No errors appear in the server logs.
Additional observations
- Existing sessions created from the mobile client appear in
opencode session list. - Existing sessions are accessible from the TUI.
- The Web UI never lists them.
- The Web UI session created through
/newis also not visible from the mobile client. - The TUI can see the session, but only contains the user's messages because the agent never starts.
Expected behavior
- Existing sessions should appear on the Web UI home page.
- It should be possible to create new sessions from the Web UI.
- Sending a message from the Web UI should start the agent exactly like TUI and mobile clients do.
Notes
This does not appear to be a networking issue:
- Health endpoint works.
- Authentication works.
- Reverse proxy works.
- TUI works.
- Attach works.
- Mobile works.
The issue seems isolated to the Web UI.
Plugins
No response
OpenCode version
1.18.14
Steps to reproduce
No response
Screenshot and/or share link
Nothing showing in home
when open /new in url a new session is opened but I dont get answe from AI
The session exists on attach (but without answer)
Operating System
No response
Terminal
No response
Reacted by Dahita
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Aug 6, 2026
This issue might be a duplicate of existing issues. Please check:
/new)If your issue is covered by one of the above, consider adding a comment there with your specific environment details (Docker + Coolify + Traefik + Cloudflare HTTPS + Basic Auth) as that reverse-proxy setup may be a useful new data point.
Dahita commentedon Aug 6, 2026
Confirmed on OpenCode v1.18.14 on WSL.
Reproduced in both Firefox and Chrome at http://127.0.0.1:4092 and a fresh instance at :4093 using --pure.
The backend is healthy:
But the web UI displays no conversations, cannot add/open a project, and controls are nonfunctional. TUI continues to work normally.
This appears to match the reported web-client regression exactly.
JohnAkindipe commentedon Aug 7, 2026
This same issue persists even in v1.18.5. The web ui is completely unusable.
daironbalens commentedon Aug 8, 2026
After two separate days of investigating this issue, I accidentally discovered that the Web UI is actually working as intended.
I'm closing the issue, but I want to document what happened because other users have reported similar behavior, and I think there are some UI/UX improvements that could prevent this confusion.
What initially looked broken
When opening the Web UI without any project added, the initial screen instructs the user to open a session to get started.
However, clicking the + / New Session button appears to do absolutely nothing: no navigation, no error, no toast, and no other feedback.
At the same time, opening Add project shows "No folders found". There is no clear indication that the user is expected to start typing a filesystem path in order to search for a project.
This combination made it look like the Web UI was unable to communicate correctly with the server or access its filesystem.
What I discovered
The missing step was simply that a project must be explicitly added/selected before a session can be created.
In the Add project dialog, typing a path such as
/my-folder/causes matching directories to appear. After selecting one:I discovered this accidentally after two days of debugging.
While testing a code change that automatically added a project, I noticed that New Session suddenly worked. When I removed that automatically added project, it stopped working again.
That led me to manually add a project in my original, completely unmodified self-hosted instance and everything worked.
So I confirmed that no code change was actually necessary.
About
/newIn my original report I also mentioned that manually opening:
https://<server>/newcreated a session, but messages sent from that session never started the agent. The user message was stored, but no assistant response was generated.
We now understand why.
By manually navigating to
/new, I was effectively forcing the application into the new-session flow without having a valid project selected. This bypassed the normal UI flow that prevents creating a session when there is no project context.In my case, this resulted in a session associated with an invalid/nonexistent directory (we observed a corrupted directory value such as
/��). The session existed, but it had no valid project/workspace context for the agent to operate in.So this behavior was another consequence of entering the new-session route without a project, rather than evidence that session execution itself was broken.
I do think this route could use some defensive handling. If
/newis opened without a valid project, the UI could:UI/UX feedback
Although this turned out not to be a functional bug, I think the current UX makes it very easy to interpret the expected behavior as a broken Web UI, especially for a first-time user.
I believe this was the main reason I initially concluded there was a bug, and it may explain why other users are reporting similar symptoms.
A few small changes could make the flow much clearer:
Initial empty state: instead of telling the user to "open a session to get started" when no project exists, instruct them to add/select a project first. Currently the UI asks the user to perform an action that cannot succeed yet.
Add project dialog: instead of only displaying "No folders found", show something like "Start typing a path to search for a project". "No folders found" strongly suggests that the server searched the filesystem and found nothing, which can easily be interpreted as a communication problem between the Web UI and the server.
New Session / + button: when no project has been added, clicking it should provide feedback for example, "Select a project before creating a session." Currently nothing happens, which makes the button appear broken.
Direct
/newnavigation: prevent creating or submitting a session without a valid project context.The backend was working correctly the entire time, but the lack of feedback at several points made the expected empty-project state look like a communication/state failure between the Web UI and the server.
Given that other users have reported similar symptoms here, the current UX may be causing the same misunderstanding for others as well.
TL;DR
The Web UI works.
A project must first be added by typing its path in the project picker and selecting it. Once a project is selected, session creation works normally.
The main issue is discoverability and feedback in the empty-project state, which can make the expected behavior look like a bug.
Hopefully this saves someone else the two days of debugging I spent figuring it out. 😅
Dahita commentedon Aug 9, 2026
Wow. Let me know where I can pay for your next coffee. Bravo on the detailed explanation and dedication. You are spot on, and this will keep happening (been seen as a bug). Thank you for your help!
troed commentedon Aug 10, 2026
I can just add to the praise. I had no idea the functionality I wanted (be able to always start opencode with host and port on my workstation - then pick up the same session from my laptop later) even existed in opencode before I read @daironbalens explanation above!