Question 1

Why does the tuios pane navigator show finished (done) panes from other sessions as unread (green ■) even after I've already viewed them?

Accepted Answer

This is a navigator rendering bug in tuios v0.10.1 and earlier. When you open the navigator (choose_tree) while attached to session A, rows for panes in other sessions are built in `navigatorSessions()` (internal/app/navigator.go) without copying the `DoneSeen` flag, so it defaults to `false` and every finished pane is drawn with the unread green ■ mark — even though the daemon state and your seen record in sidebar.json are correct. The mark only displays correctly while you are attached to that same session.

Fix: upgrade tuios. The bug was fixed in PR #910 (the navigator now copies `DoneSeen` and `Subagents` from the session tree, and screen loading no longer re-adds the unread mark). The fix is on `main` and included in the release after v0.10.1.

Workaround on affected versions: attach to the session containing the done pane and open the navigator there — the attached-session branch reads the seen state correctly, so the pane shows the muted ○ mark as expected.

Question 2

How to disable the sidebar peek on session hover in tuios (stop terminals list from swapping when hovering sessions)?

Accepted Answer

Add the peek option under `[appearance.sidebar]` in your tuios config file:

```toml
[appearance.sidebar]
peek = false
```

Alternatively, toggle it live from the command line:

```
tuios set-config appearance.sidebar.peek false
```

You can also change it on the settings page under the **Sidebar** section. With peek disabled, the terminals section keeps showing the attached session's panes when hovering over session rows or moving the rail cursor — it only changes when you click to attach another session. The option was added in PR #1241 and defaults to enabled (`true`), so existing behavior is unchanged unless you turn it off.

Question 3

Why does tuios new-window ignore the BSP preselection direction (Preselect left/right) and split in the wrong direction?

Accepted Answer

This is a bug in tuios v0.11.0: panes created externally via `tuios new-window --cwd ...` bypass the client's BSP preselection because `insertSyncedWindow` only reads the recorded pending split (set by the in-client `n` path) and never consumes `PreselectionDir`. The pane lands using the layout scheme's default direction (e.g., below instead of left). Fix: upgrade to a build containing PR #1246, which makes the client apply its preselection on the focused pane when no native split is recorded and clears it only after the window is actually inserted — `Preselect left` followed by `new-window --cwd ...` then places the pane on the left from the first frame. Workaround on v0.11.0: create the pane first, then rotate the split to the desired side, though the incorrect initial placement may briefly be visible.

Question 4

Why does Codex activity from Ghostty Quick Terminal appear under the wrong TUIOS pane?

Accepted Answer

Cause: Codex runs hooks for every conversation through one shared app-server process, which inherits the environment (TUIOS_PANE_ID, TUIOS_PANE_TTY) of the TUIOS pane it was first launched in. When a conversation from an external terminal like Ghostty Quick Terminal requests approval, the `tuios agent-hook codex` hook misattributes the event to that original pane, triggering wrong sidebar activity and macOS notifications.

Fix: Update TUIOS to a version including PR #882 (merged to main after v0.10.0). The fix marks Codex as a shared-server harness: another conversation on the same server can only claim a pane when it starts or resumes a thread, never mid-turn, and the pane's own conversation reclaims it on its next report so its approvals are never hidden. Compaction no longer counts as a new conversation. Upgrade via Homebrew once the next release ships, or build from the main branch as a workaround.

Question 5

Why do tuios keybindings trigger the wrong actions on French AZERTY or other non-US keyboard layouts, and how to fix it?

Accepted Answer

tuios applied US shifted-digit aliases (`&` = Shift+7, `(` = Shift+9, `!` = Shift+1) globally, so on AZERTY—where `&`, `(`, `!` are unshifted keys—`opt+&` matched `move_and_follow_7` instead of workspace 1, and the alias won over custom bindings by alphabetical name order. Fix: upgrade to a tuios build including PR #578, which moves US aliases into a separate lower-priority tier so an explicit binding like `switch_workspace_1 = ['opt+&']` always wins over any alias. Workaround for the hardcoded review overlay keys `[ ] { }` (tracked in issue #585): in iTerm2 set Left Option to "Esc+" for tuios bindings and Right Option to "Normal", so you can still type `[ ] { } |` on AZERTY while tuios bindings keep working.

tuios

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects