Repository navigation
[BUG] session_list returns empty despite sessions existing in database #15108
Description
Bug Report: session_list Returns Empty Despite Sessions Existing in Database
Date: 2026-02-25
User: gromada project (/home/lu/Documents/gromada)
OpenCode Version: 1.2.13
Summary
The session_list tool returns an empty list despite sessions existing in the SQLite database. Sessions ARE being saved correctly to ~/.local/share/opencode/opencode.db, but the list function fails to return them.
Reproduction
- User works on project
/home/lu/Documents/gromadafor several hours - Multiple sessions are created and saved (verified in database)
- User runs
session_list()- returns empty list[] - User runs
session_search()- finds sessions successfully - User runs direct SQL query - sessions exist in database
Evidence
Database Query (works correctly)
SELECT id, slug, title, time_created
FROM session
WHERE project_id = '0414ba0fb05af3df687d6e70501ee7febfcc7f8d'
ORDER BY time_created DESC;Returns: 100+ sessions including:
ses_36a097a42ffepWYz5H1l6jJKOY(current session, 18:01)ses_36a341e68ffe2PEYbaF2Yqe7sW(17:14)ses_36ae4dc54ffeb42G7NrhUIAx4k(14:01)ses_36b7be405ffebyxrRCtLTlh8uZ(11:16)
session_list (returns empty)
session_list({})
// Returns: []session_search (works correctly)
session_search({query: "gromada"})
// Returns: Found matches with session dataAnalysis
The sessions ARE being saved correctly to the database. The bug appears to be in the session_list function implementation, not in the session saving mechanism.
Possible causes:
- Query filtering issue - session_list may be applying incorrect filters (e.g., filtering by wrong project_id, date range, or archived status)
- Database connection issue - session_list may not be connecting to the correct database or using correct schema
- API response handling - the list may be returned but filtered out before being returned to the user
Impact
- Users cannot see their session history through the list interface
- Users must use
session_searchto find sessions (workaround works) - Users must know exact session IDs to resume sessions
Recommendation
Investigate the session_list function implementation:
- Check the SQL query being generated
- Verify filtering parameters (project_id, date range)
- Check for any error handling that might suppress results
- Compare with
session_searchimplementation to identify differences
Workaround
Use session_search() with a query term to find sessions, or query the database directly:
sqlite3 ~/.local/share/opencode/opencode.db "SELECT id, title, time_created FROM session WHERE directory LIKE '%gromada%' ORDER BY time_created DESC LIMIT 20;"Reacted by Luka Boulpaep and Alex Povel
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Feb 25, 2026
This issue might be a duplicate of an existing issue. Please check:
--project-pathequals current directory — same symptom ofsession_listreturning an empty list despite sessions existing in the database. The underlying cause may be the same.lukaboulpaep commentedon Feb 25, 2026
Having the same problem
huayu0721 commentedon Mar 7, 2026
A possible temporary solution ：entry
~/.local/share/opencode/storageand runopencode db migrate,then my sessions came backcodeg-old commentedon May 8, 2026
Additional reproduction on macOS with OpenCode
1.14.41.Observed behavior:
opencode session list -n 5 --format jsonreturns recent sessions normally for the active project.session_list({ project_path: <active project path> })returnsNo sessions found.session_info(session_id)succeeds and reports message count/date range/transcript metadata.session_read(session_id)fails withSession not found.session_search(...)also returns no matches for terms present in the active session context.~/.local/share/opencode/storage/session/) exists but contains0entries.opencode db pathpoints to the SQLite DB under the normal OpenCode data directory.This looks like the session tools and the CLI/runtime are not reading the same source of truth. The CLI sees sessions in the current SQLite-backed store, while
session_list/session_readappear to miss them, possibly by consulting legacy file storage or applying a different project/session filter.I did not modify the database while testing; the checks above used the OpenCode CLI plus the session MCP/tool surface.
Authorship disclosure: this reproduction note was prepared with AI assistance.
codeg-old commentedon May 9, 2026
Related PR for the TUI session picker side: #26432.
That PR fixes the root-session dilution in the TUI dialog by querying root sessions directly for
/sessionswhile leaving the shared session bootstrap unchanged for child-session navigation.It does not claim to fix the separate MCP/session-tool source-of-truth mismatch reported here (
session_list/session_readbehavior). I am calling that out so the two layers do not get conflated.Authorship disclosure: prepared with AI assistance.
github-actions commentedon Jul 9, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.