anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Closed
opened 2026-02-16 17:33:38 -05:00 by yindo · 12 comments
yindo commented 2026-02-16 17:33:38 -05:00
Owner
Copy Link
Copy Source

Originally created by @randomm on GitHub (Oct 8, 2025).

Originally assigned to: @thdxr on GitHub.

Environment:

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

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

Reproduction:

  1. Have sessions from v0.13.x or earlier
  2. Upgrade to v0.14.4+
  3. 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 10998d62: session API reliability changes
  • Issue #2987: session loss after /compact
Originally created by @randomm on GitHub (Oct 8, 2025). Originally assigned to: @thdxr on GitHub. **Environment:** - OpenCode v0.14.6, macOS - Affected since v0.14.4 (session API changes, commit 10998d62) **Issue:** `/sessions` command shows "No sessions available" when sessions physically exist in storage. **Reproduction:** 1. Have sessions from v0.13.x or earlier 2. Upgrade to v0.14.4+ 3. Run `/sessions` - shows empty **Evidence:** ```bash # 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 10998d62: session API reliability changes - Issue #2987: session loss after `/compact`
yindo closed this issue 2026-02-16 17:33:38 -05:00
yindo commented 2026-02-16 17:33:39 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Oct 8, 2025):

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

  • #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.

@github-actions[bot] commented on GitHub (Oct 8, 2025): This issue might be a duplicate of existing issues. Please check: - #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.
yindo commented 2026-02-16 17:33:39 -05:00
Author
Owner
Copy Link
Copy Source

@randomm commented on GitHub (Oct 8, 2025):

Update: More severe than version compatibility

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

Test:

  1. Created new session at 07:42 (v0.14.6)
  2. Exited with ctrl+c
  3. Restarted opencode
  4. /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 commented on GitHub (Oct 8, 2025): **Update: More severe than version compatibility** Sessions created in v0.14.6 also don't appear in `/sessions` list. **Test:** 1. Created new session at 07:42 (v0.14.6) 2. Exited with ctrl+c 3. Restarted opencode 4. `/sessions` → "No sessions available" **Evidence:** ```bash # 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.
yindo commented 2026-02-16 17:33:39 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 8, 2025):

@randomm ill send some debug commands shortly

@rekram1-node commented on GitHub (Oct 8, 2025): @randomm ill send some debug commands shortly
yindo commented 2026-02-16 17:33:39 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 8, 2025):

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

@rekram1-node commented on GitHub (Oct 8, 2025): So in the project that has no sessions anymore, if you run: `git rev-list --max-parents=0 --all` do you see `de19ee09d010e956a30a119287a1b94f91b5cff2`?
yindo commented 2026-02-16 17:33:39 -05:00
Author
Owner
Copy Link
Copy Source

@randomm commented on GitHub (Oct 8, 2025):

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.

@randomm commented on GitHub (Oct 8, 2025): **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`: ```go 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`: ```ts const directory = c.req.query("directory") ?? process.cwd() // ← Falls back to server's cwd ``` `packages/opencode/src/session/index.ts:274`: ```ts 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.
yindo commented 2026-02-16 17:33:39 -05:00
Author
Owner
Copy Link
Copy Source

@randomm commented on GitHub (Oct 8, 2025):

@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.

@randomm commented on GitHub (Oct 8, 2025): @rekram1-node Yes, confirmed: ```bash $ 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.
yindo commented 2026-02-16 17:33:39 -05:00
Author
Owner
Copy Link
Copy Source

@randomm commented on GitHub (Oct 8, 2025):

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!

@randomm commented on GitHub (Oct 8, 2025): ### 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!
yindo commented 2026-02-16 17:33:39 -05:00
Author
Owner
Copy Link
Copy Source

@randomm commented on GitHub (Oct 8, 2025):

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!

@randomm commented on GitHub (Oct 8, 2025): ### 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!
yindo commented 2026-02-16 17:33:39 -05:00
Author
Owner
Copy Link
Copy Source

@randomm commented on GitHub (Oct 8, 2025):

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.

@randomm commented on GitHub (Oct 8, 2025): 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.
yindo commented 2026-02-16 17:33:39 -05:00
Author
Owner
Copy Link
Copy Source

@randomm commented on GitHub (Oct 8, 2025):

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.

@randomm commented on GitHub (Oct 8, 2025): ### 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.
yindo commented 2026-02-16 17:33:39 -05:00
Author
Owner
Copy Link
Copy Source

@randomm commented on GitHub (Oct 8, 2025):

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

@randomm commented on GitHub (Oct 8, 2025): Unfortunately this still does not fix the issue on my local machine. Continuing debugging...
yindo commented 2026-02-16 17:33:39 -05:00
Author
Owner
Copy Link
Copy Source

@manascb1344 commented on GitHub (Jan 27, 2026):

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)
@manascb1344 commented on GitHub (Jan 27, 2026): This bug also affects **project-local skills discovery** when using `opencode attach`. When I run: ```bash 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)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1993
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?