bug: TUI sessions don't record cwd — Desktop groups them under default workspace

[Prontsevich]

Bug: TUI sessions don't record cwd — Desktop groups them under default workspace

_launch_cwd_for_session() in run_agent.py only records cwd when source == "cli". TUI sessions (source == "tui") get cwd = NULL, so the Desktop GUI cannot group them by workspace — they all land in the default/"No workspace" group.

Steps to reproduce

1. cd ~/Documents/pa && hermes --tui
2. Start a new session
3. Open Desktop GUI — the session appears under the default workspace, not under a "pa" workspace

Root cause

run_agent.py:80:

def _launch_cwd_for_session(source: str) -> Optional[str]:
    if source != "cli":  # <-- TUI excluded
        return None

All TUI sessions in state.db show cwd = /Users/lestroy (home) or NULL, regardless of the actual launch directory.

Suggested fix

if source not in ("cli", "tui"):
    return None

Related issues

• Desktop/TUI compressed sessions can move into No workspace because continuation cwd is null #42228 — compressed sessions losing cwd (different bug, but related)
• Desktop: make workspace selectable per session, not only launch-time cwd #40297 — workspace selectable per session
• WebUI: CLI sessions imported from state.db ignore original cwd, always use get_last_workspace() #48782 — WebUI ignoring cwd from state.db

[Prontsevich]

Update: Root cause found in tui_gateway/server.py

The initial diagnosis pointed at run_agent.py:_launch_cwd_for_session(), but TUI sessions are created through a different code path — tui_gateway/server.py:_ensure_session_db_row().

Actual root cause

_ensure_session_db_row() at line 1313:

cwd=_session_cwd(session) if session.get("explicit_cwd") else None,

explicit_cwd is only True when the Desktop GUI client explicitly sends a cwd parameter in session.create. Running hermes --tui from a terminal never sets this flag, so all TUI sessions get cwd = NULL.

Fix

Always pass _session_cwd(session) (which falls back to os.getcwd()):

cwd=_session_cwd(session),

See PR #50440.

[bgexpert]

Confirmed on 0.18.2 — and it also breaks project grouping, not just the default workspace.

The OP's run_agent.py:_launch_cwd_for_session() reference no longer matches the current code; the live logic is in tui_gateway/server.py. Same behavior, here is the current root cause with a Desktop repro.

Current root cause (0.18.2):
In session.create (tui_gateway/server.py):

raw_cwd = str(params.get("cwd") or "").strip()
explicit_cwd = bool(raw_cwd) and os.path.isdir(os.path.abspath(os.path.expanduser(raw_cwd)))
...
"explicit_cwd": explicit_cwd,   # ~line 5268

and only when explicit_cwd is true is the cwd persisted to state.db (_ensure_session_db_row, ~line 1764):

cwd=_session_cwd(session) if session.get("explicit_cwd") else None,

So a session is bound to a folder/project only if the client passes a non-empty, existing cwd in the session.create call.

Empirical evidence (real state.db, 484 sessions):

• TUI sessions with cwd = NULL: 245 of 349 (70%)
• i.e. the Desktop client does not transmit cwd when starting a chat, even when the user is "inside" a project.

Why this also makes project chats vanish:
The Desktop sidebar groups sessions into a project by longest-prefix match of sessions.cwd against project_folders.path (tui_gateway/project_tree.py::_FolderIndex.match). A NULL cwd matches nothing, so a chat started inside a project is filed under "No workspace" and disappears from that project's view. (The chat is not deleted — build_tree still returns it correctly if cwd is set; the row simply never receives the cwd.)

Steps to reproduce (Desktop, Windows 10, 0.18.2):

1. Create a project whose primary folder is a non-git directory.
2. Open that project in the Desktop sidebar and start a new chat there.
3. Send a message (so a state.db row is created).
4. Inspect state.db → the new session row has cwd = NULL.
5. Result: the chat does not appear under the project; the project shows only chats whose cwd happened to be transmitted (here, 2 of many).

Suggested fix: when a session.create is scoped to the active project (the gateway already knows the active project scope for new sessions), inherit that project's primary folder as explicit_cwd when the client sent none — or persist the active project scope id separately so project_tree can group by project id, not only by cwd prefix match.

Happy to share the state.db query counts (no paths/PII) if useful.

[GottZ]

This was generated by AI during triage.

Summary

Four of the seven listed PRs directly address #50438: #50440 removes the server-side explicit-workspace guard, #50586 distinguishes stdio TUI from WebSocket sessions, #50759 broadens the later run_agent cwd allowlist, and #64861 makes the TUI client explicitly send its launch cwd. #66446 concerns durable exit breadcrumbs, while #67268 and #67294 address pending-prompt rehydration for #67265 rather than the cwd-persistence cause in #50438.

Related pull requests

• fix(agent): record cwd for TUI sessions #50440 [closed] partial — (+1/-1) — partial fix, closed and superseded by fix(tui): pass launch cwd in session.create so Desktop groups TUI sessions #64861: it unconditionally persists the gateway-resolved cwd, which fixes NULL cwd but violates the documented explicit-workspace guard and can assign the Desktop gateway's shared launch directory. Despite the keep_open review on fix(agent): record cwd for TUI sessions #50440, the subsequent diff in fix(tui): pass launch cwd in session.create so Desktop groups TUI sessions #64861 preserves that guard and supplies cwd at the correct client boundary.
• fix(agent): record cwd for TUI-created sessions #50586 fixes — (+78/-0) — fixes via an alternative mechanism: it marks cwd explicit only for the module-level stdio transport and preserves unworkspaced WebSocket sessions, with positive and negative gateway tests. Despite the keep_open review on fix(agent): record cwd for TUI-created sessions #50586, fix(tui): pass launch cwd in session.create so Desktop groups TUI sessions #64861 is the narrower client-side fix because its diff uses the launcher's existing HERMES_CWD and leaves server transport semantics unchanged.
• fix(agent): record cwd for TUI sessions so Desktop can group them (#50438) #50759 partial — (+95/-5) — partial fix: it allows source='tui' in run_agent._launch_cwd_for_session, but the gateway creates the row earlier and its later upsert can override the intentional explicit-workspace default. Despite the keep_open review on fix(agent): record cwd for TUI sessions so Desktop can group them (#50438) #50759, the diff targets a downstream helper rather than the request path that determines explicit_cwd.
• fix(tui): pass launch cwd in session.create so Desktop groups TUI sessions #64861 best fix — (+91/-1) — best fix: the TUI sends HERMES_CWD (falling back to process.cwd()) in session.create, so the existing gateway validation and explicit_cwd persistence contract record the real launch workspace. It also includes the Vitest regression coverage requested by the keep_open review on fix(tui): pass launch cwd in session.create so Desktop groups TUI sessions #64861.
• fix(tui): keep exit summary on durable session #66446 unrelated — (+242/-14) — unrelated to bug: TUI sessions don't record cwd — Desktop groups them under default workspace #50438: it tracks durable session IDs for exit breadcrumbs across create, resume, compression, and branch flows, without changing cwd transmission or persistence. It remains relevant to its own session-identity problem, not this consolidation.
• fix(tui): rehydrate pending prompts after live session resume #67268 unrelated — (+198/-10) — unrelated to bug: TUI sessions don't record cwd — Desktop groups them under default workspace #50438: it rehydrates saved clarify, sudo, and secret prompts on live-session resume or activation for Dashboard Chat: returning to a session loses pending clarify prompt #67265, with gateway and lifecycle tests. It does not modify session.create cwd handling.
• fix(dashboard): restore pending clarify prompts on session return (#67265) #67294 unrelated — (+97/-0) — unrelated to bug: TUI sessions don't record cwd — Desktop groups them under default workspace #50438 and competing with fix(tui): rehydrate pending prompts after live session resume #67268 for Dashboard Chat: returning to a session loses pending clarify prompt #67265: it restores pending overlays but its approval path reads the wrong pending store, snapshots without the prompt lock, and adds no regression tests. Its keep_open review should be resolved within the separate Dashboard Chat: returning to a session loses pending clarify prompt #67265 cluster.

Duplicates

#50586 and #64861 are functional duplicates for #50438 through different layers; #50440 and #50759 pursue broader alternatives but do not implement the same diff. #67268 and #67294 overlap with each other for #67265, not with the cwd fix.

Suggested consolidation

Merge #64861 — it directly supplies the launch cwd at session.create, preserves the server's explicit-workspace contract, and now contains the requested client regression test. Close #50586 and #50759 as superseded alternative fixes; keep closed #50440 as superseded by #64861. Exclude #66446, #67268, and #67294 from #50438 consolidation and triage them under their own issue complexes.

Complex graph

flowchart TD
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I50438(["issue #50438 (open)"])
    I67265(["issue #67265 (open)"])
    P50440["PR #50440 (closed)"]
    P50586["PR #50586 (open)"]
    P50759["PR #50759 (open)"]
    P64861["PR #64861 (open)"]
    P67268["PR #67268 (open)"]
    P67294["PR #67294 (open)"]
    P50440 -.->|partial| I50438
    P50586 -->|fixes| I50438
    P50759 -.->|partial| I50438
    P64861 -->|best fix| I50438
    P67268 -->|best fix| I67265
    P67294 -.->|partial| I67265
    class I50438 open
    class I67265 open
    class I50438 target
    class P50440 closed
    class P50586 open
    class P50759 open
    class P64861 open
    class P67268 open
    class P67294 open
    class P64861 best
    class P67268 best
    click I50438 "https://github.com/NousResearch/hermes-agent/issues/50438"
    click I67265 "https://github.com/NousResearch/hermes-agent/issues/67265"
    click P50440 "https://github.com/NousResearch/hermes-agent/pull/50440"
    click P50586 "https://github.com/NousResearch/hermes-agent/pull/50586"
    click P50759 "https://github.com/NousResearch/hermes-agent/pull/50759"
    click P64861 "https://github.com/NousResearch/hermes-agent/pull/64861"
    click P67268 "https://github.com/NousResearch/hermes-agent/pull/67268"
    click P67294 "https://github.com/NousResearch/hermes-agent/pull/67294"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed or no verify verdict yet (state tag in the node label).

Cross-PR triage: Reviewed 7 pull requests and 2 issues in this complex. Each diff was read against this issue; Assessment working set: 50 kB of PR diffs, 15 kB of issue/PR text, 17 kB of discussion (16 comments), 16 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.