Resume hint omits session id; run --continue is ambiguous with multiple sessions per workspace

[7jrxt42BxFZo4iAnN4CX]

Problem

After an interactive session exits, the TUI prints only:

To continue this session, execute codewhale run --continue

run --continue resumes the most recent interactive session for the current workspace. When a workspace has several recent interactive sessions (I currently have three in one folder), the hint is ambiguous: the command silently picks the most recent one, which may not be the session I just left. Nothing in the hint says which session will be resumed.

To resume a specific session I must run codewhale sessions, read the id, then codewhale resume <id> — two extra steps, and the id is never shown at exit.

Who is affected: anyone who keeps multiple concurrent sessions in one workspace (common when working across subtasks, or after crashes/kill -9 leave several "recent" sessions).

Proposed solution

Show the session id at exit and/or let the user choose, e.g.:

• To continue this session, execute codewhale resume 05221f3f (real id), and/or
• when the workspace has more than one recent interactive session, make run --continue interactive (session picker) instead of silently resuming the newest.

Suggest a config option, e.g. tui.resume_hint = "command" | "id" | "both", editable via /config like other [tui] keys. Default: current behavior (no id). The id should only ever be printed on an interactive TTY at exit, never when stdout is redirected or in logs.

Use case

I close a session, come back minutes/hours later, and want to continue that one. With several sessions in the same workspace run --continue often lands in the wrong one, and I cannot tell which from the hint. opencode handles this with a session picker; I'd like the same.

Alternatives considered

• codewhale sessions + codewhale resume <id> manually (works, but the id is not shown at exit and it is two extra steps).
• A shell wrapper/hook on session_end that prints the id myself (fragile, per-shell).
• Making --continue interactive only when ambiguous (picker) — my preferred alternative to a config key.

Impact

I would use this every session close; it removes a frequent source of "wrong session resumed" and the need to cross-reference codewhale sessions output.

Additional context

The id used to be in the hint and was removed deliberately in f5784909c (security: avoid session-id taint) and reworded in 0388a5510 — hence the current constant string in resume_hint_text() (crates/tui/src/tui/ui.rs, called from event_loop.rs). A config-gated, TTY-only id would preserve that security intent while fixing the ambiguity.

Related but different: #5999 (offline-queue wedge behind stacked session-identity notices).

[github-actions]

Thanks @7jrxt42BxFZo4iAnN4CX for the report.

This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.

If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment /lgtmi to mark recurring issue reporters as approved so this intake note is skipped next time.

[Hmbown]

Problem

After an interactive session exits, the TUI prints only:

To continue this session, execute codewhale run --continue

run --continue resumes the most recent interactive session for the current workspace. When a workspace has several recent interactive sessions (I currently have three in one folder), the hint is ambiguous: the command silently picks the most recent one, which may not be the session I just left. Nothing in the hint says which session will be resumed.

To resume a specific session I must run codewhale sessions, read the id, then codewhale resume <id> — two extra steps, and the id is never shown at exit.

Who is affected: anyone who keeps multiple concurrent sessions in one workspace (common when working across subtasks, or after crashes/kill -9 leave several "recent" sessions).

Proposed solution

Show the session id at exit and/or let the user choose, e.g.:

• To continue this session, execute codewhale resume 05221f3f (real id), and/or
• when the workspace has more than one recent interactive session, make run --continue interactive (session picker) instead of silently resuming the newest.

Suggest a config option, e.g. tui.resume_hint = "command" | "id" | "both", editable via /config like other [tui] keys. Default: current behavior (no id). The id should only ever be printed on an interactive TTY at exit, never when stdout is redirected or in logs.

Use case

I close a session, come back minutes/hours later, and want to continue that one. With several sessions in the same workspace run --continue often lands in the wrong one, and I cannot tell which from the hint. opencode handles this with a session picker; I'd like the same.

Alternatives considered

• codewhale sessions + codewhale resume <id> manually (works, but the id is not shown at exit and it is two extra steps).
• A shell wrapper/hook on session_end that prints the id myself (fragile, per-shell).
• Making --continue interactive only when ambiguous (picker) — my preferred alternative to a config key.

Impact

I would use this every session close; it removes a frequent source of "wrong session resumed" and the need to cross-reference codewhale sessions output.

Additional context

The id used to be in the hint and was removed deliberately in f5784909c (security: avoid session-id taint) and reworded in 0388a5510 — hence the current constant string in resume_hint_text() (crates/tui/src/tui/ui.rs, called from event_loop.rs). A config-gated, TTY-only id would preserve that security intent while fixing the ambiguity.

Related but different: #5999 (offline-queue wedge behind stacked session-identity notices).

Thank you so much for filing this!! So appreciated