/sessions shows empty despite sessions existing in storage (v0.14.6)

Environment:

OpenCode v0.14.6, macOS
Affected since v0.14.4 (session API changes, commit 10998d6)

Issue:
/sessions command shows "No sessions available" when sessions physically exist in storage.

Reproduction:

Have sessions from v0.13.x or earlier
Upgrade to v0.14.4+
Run /sessions - shows empty

Evidence:

# 32 parent sessions exist in storage:
$ grep -L '"parentID"' ~/.local/share/opencode/storage/session/<project-id>/*.json | wc -l
32

# Sessions are valid JSON with correct structure
$ cat session/ses_*.json
{
  "id": "ses_66a71b6f4ffeq796jvvOpJQ04m",
  "version": "0.13.4",  # Mix of v0.13.4 and v0.14.5 sessions
  "projectID": "de19ee09d010e956a30a119287a1b94f91b5cff2",
  ...
}

Hypothesis:
Session loading broken for v0.13.x sessions after v0.14.4 API changes.

Related:

Commit 10998d6: session API reliability changes
Issue [Bug] All sessions are gone #2987: session loss after /compact

This issue might be a duplicate of existing issues. Please check:

[Bug] All sessions are gone #2987: [Bug] All sessions are gone - Also involves session loss/visibility issues, specifically mentions sessions disappearing after running /compact command, which could be related to session loading problems in upgraded versions

Feel free to ignore if none of these address your specific case.

Update: More severe than version compatibility

Sessions created in v0.14.6 also don't appear in /sessions list.

Test:

Created new session at 07:42 (v0.14.6)
Exited with ctrl+c
Restarted opencode
/sessions → "No sessions available"

Evidence:

# Session exists in storage:
$ cat session/ses_63ddf0e64ffeexMyAfnTuEkMqu.json
{
  "id": "ses_63ddf0e64ffeexMyAfnTuEkMqu",
  "version": "0.14.6",  # Same version
  "projectID": "de19ee09d010e956a30a119287a1b94f91b5cff2",
  "directory": "/Users/janni/git/cantoriam/cantoriam-app",
  "title": "Starting new CLI session",  # Parent session (no parentID)
  "time": {
    "created": 1759898562971,
    "updated": 1759898569296
  }
}

Session listing appears completely broken, not just cross-version incompatibility.

@randomm

@randomm ill send some debug commands shortly

So in the project that has no sessions anymore, if you run: git rev-list --max-parents=0 --all do you see de19ee09d010e956a30a119287a1b94f91b5cff2?

Root cause found:

The TUI doesn't pass the directory parameter when calling session list API.

Code locations (v0.14.6):

packages/tui/internal/app/app.go:907:

func (a *App) ListSessions(ctx context.Context) ([]opencode.Session, error) {
    response, err := a.Client.Session.List(ctx, opencode.SessionListParams{})  // ← Empty params!
    ...
}

packages/opencode/src/server/server.ts:95:

const directory = c.req.query("directory") ?? process.cwd()  // ← Falls back to server's cwd

packages/opencode/src/session/index.ts:274:

export async function* list() {
  const project = Instance.project  // ← Uses wrong project (from process.cwd())
  for (const item of await Storage.list(["session", project.id])) {
    yield Storage.read<Info>(item)
  }
}

Issue:

TUI passes empty SessionListParams{} (no directory)
Server defaults to its own process.cwd() instead of user's working directory
Sessions are looked up for wrong project ID

Same bug affects:

Session.New() (line 776)
Session.Delete() (line 919)
Project.Current() (main.go:75)
All other API calls with empty params

Fix needed:
TUI should pass current directory in all API params, or SDK client should be configured with default directory.

@rekram1-node

@rekram1-node Yes, confirmed:

$ git rev-list --max-parents=0 --all
de19ee09d010e956a30a119287a1b94f91b5cff2

The project ID matches exactly. Sessions exist in storage at the correct path with 32 parent sessions + 413 child sessions, but /sessions shows empty.

Additional Context (potentially helpful for fix)

Found 13 locations in TUI where directory parameter is not passed to API calls. All use empty params like SessionListParams{}:

main.go (initial setup):

L75: ProjectCurrentParams{}
L84: AgentListParams{}
L93: PathGetParams{}
L139: EventListParams{}

app.go (session operations):

L117: ConfigGetParams{}
L192: CommandListParams{}
L464, L961: AppProvidersParams{}
L776: SessionNewParams{} (affects session creation)
L898: SessionAbortParams{}
L907: SessionListParams{} (why /sessions shows empty)
L919: SessionDeleteParams{} (potentially dangerous)
L939: SessionMessagesParams{}

Possible fix approach:
All locations need Directory: opencode.F(a.Project.Worktree) added to params (where a.Project is available).

Note: Not sure why this worked in earlier versions - perhaps the server was launched from user's working directory previously, making process.cwd() fallback correct? Just trying to understand the regression context.

Happy to provide more details if helpful!

Possible explanation for regression

The TUI has never populated directory params in API calls (checked git history). It may have worked previously if the server's process.cwd() fallback happened to match the user's project directory.

Something may have changed in how/where the server process starts, causing process.cwd() to point elsewhere. This would explain why old sessions exist in storage but aren't visible - created under one project ID, looked up under another.

Just a theory though - could be completely off!

Hmm, stop press. /sessions works in new projects, but not in existing projects with many sessions. I will look into this more deeply to make sure now.

Update: NEW vs EXISTING projects behavior

Just tested and confirmed /sessions works in NEW projects but not EXISTING ones.

Why this happens:

NEW projects often work by accident because the server's process.cwd() happens to match the project directory. EXISTING projects fail when these don't align.

The flow:

TUI calls API (no directory param)
  → Server defaults to process.cwd()
  → Instance caches project by that directory
  → Sessions looked up using wrong project ID

So the original fix still applies - TUI needs to pass directory parameter to ensure correct project context regardless of where the server started.

I'll see if I can provide a PR for a fix.

fix(tui): pass directory parameter to all API calls

Unfortunately this still does not fix the issue on my local machine. Continuing debugging...

This bug also affects project-local skills discovery when using opencode attach.

When I run:

cd /home/me && opencode serve
cd /home/me/projects/my-app && opencode attach http://127.0.0.1:4096

The server discovers skills starting from /home/me (its own process.cwd()), not from /home/me/projects/my-app where the TUI is running.
According to the documentation (https://opencode.ai/docs/skills/):

"For project-local paths, OpenCode walks up from its current working directory until it reaches the git worktree."

Because the TUI doesn't pass the working directory to the server, skills discovery starts in the wrong directory and never finds:

./.claude/skills/*/SKILL.md (project-local)
./.opencode/skills/*/SKILL.md (project-local)

Navigation Menu

Repository navigation

/sessions shows empty despite sessions existing in storage (v0.14.6) #3026

Additional Context (potentially helpful for fix)

Possible explanation for regression

Update: NEW vs EXISTING projects behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

/sessions shows empty despite sessions existing in storage (v0.14.6) #3026

Description

Activity

github-actions commented on Oct 8, 2025

randomm commented on Oct 8, 2025

rekram1-node commented on Oct 8, 2025

rekram1-node commented on Oct 8, 2025

randomm commented on Oct 8, 2025

randomm commented on Oct 8, 2025

randomm commented on Oct 8, 2025

Additional Context (potentially helpful for fix)

randomm commented on Oct 8, 2025

Possible explanation for regression

randomm commented on Oct 8, 2025

randomm commented on Oct 8, 2025

Update: NEW vs EXISTING projects behavior

randomm commented on Oct 8, 2025

manascb1344 commented on Jan 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions