Question 1

이미 확인했는데도 tuios pane navigator가 다른 세션의 완료된(done) pane을 읽지 않음(녹색 ■)으로 표시하는 이유는 무엇인가요?

Accepted Answer

이것은 tuios v0.10.1 및 이전 버전에서 발생하는 navigator 렌더링 버그입니다. 세션 A에 연결된 상태에서 navigator(choose_tree)를 열면, 다른 세션의 pane에 대한 행이 `navigatorSessions()`(internal/app/navigator.go)에서 `DoneSeen` 플래그를 복사하지 않은 채 생성되어 기본값인 `false`가 되므로, daemon 상태와 sidebar.json의 seen 기록이 올바르더라도 완료된 모든 pane에 읽지 않은 녹색 ■ 표시가 그려집니다. 이 표시는 동일한 세션에 연결되어 있을 때만 올바르게 표시됩니다.

수정 방법: tuios를 업그레이드하세요. 이 버그는 PR #910에서 수정되었습니다(navigator가 이제 세션 트리에서 `DoneSeen`과 `Subagents`를 복사하고, 화면 로딩 시 읽지 않은 표시를 더 이상 다시 추가하지 않습니다). 이 수정 사항은 `main`에 있으며 v0.10.1 이후 릴리스에 포함되어 있습니다.

영향을 받는 버전에서의 우회 방법: 완료된 pane이 있는 세션에 연결하여 그곳에서 navigator를 여세요. 연결된 세션 분기는 seen 상태를 올바르게 읽으므로 pane에 예상대로 흐릿한 ○ 표시가 나타납니다.

Question 2

tuios에서 세션 호버 시 sidebar peek을 비활성화하는 방법(세션에 마우스를 올릴 때 터미널 목록이 바뀌는 것을 막으려면)?

Accepted Answer

tuios 설정 파일에서 `[appearance.sidebar]` 아래에 peek 옵션을 추가하세요:

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

또는 명령줄에서 실시간으로 전환할 수 있습니다:

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

설정 페이지의 **Sidebar** 섹션에서도 변경할 수 있습니다. peek이 비활성화되면 세션 행 위로 마우스를 올리거나 rail 커서를 이동할 때 터미널 섹션이 연결된 세션의 패인을 계속 표시하며, 다른 세션을 클릭하여 연결할 때만 변경됩니다. 이 옵션은 PR #1241에서 추가되었으며 기본값은 활성화(`true`)이므로, 비활성화하지 않는 한 기존 동작은 그대로 유지됩니다.

Question 3

tuios new-window가 BSP 사전 선택 방향(Preselect left/right)을 무시하고 잘못된 방향으로 분할하는 이유는 무엇인가요?

Accepted Answer

이것은 tuios v0.11.0의 버그입니다: `tuios new-window --cwd ...`를 통해 외부에서 생성된 pane은 클라이언트의 BSP preselection을 우회합니다. `insertSyncedWindow`가 기록된 pending split(클라이언트 내 `n` 경로에서 설정됨)만 읽고 `PreselectionDir`을 전혀 소비하지 않기 때문입니다. 그 결과 pane은 레이아웃 스킴의 기본 방향(예: 왼쪽 대신 아래쪽)으로 배치됩니다. 수정 방법: PR #1246이 포함된 빌드로 업그레이드하세요. 이 PR은 기록된 네이티브 split이 없을 때 클라이언트가 포커스된 pane에 preselection을 적용하고, window가 실제로 삽입된 후에만 이를 지우도록 합니다. 따라서 `Preselect left` 다음에 `new-window --cwd ...`를 실행하면 첫 프레임부터 pane이 왼쪽에 배치됩니다. v0.11.0에서의 우회 방법: 먼저 pane을 생성한 다음 split을 원하는 쪽으로 회전하세요. 다만 잘못된 초기 배치가 잠시 보일 수 있습니다.

Question 4

Ghostty Quick Terminal의 Codex 활동이 잘못된 TUIOS pane 아래에 표시되는 이유는 무엇인가요?

Accepted Answer

원인: Codex는 모든 대화에 대해 하나의 공유 app-server 프로세스를 통해 hook을 실행하며, 이 프로세스는 처음 실행된 TUIOS pane의 환경(TUIOS_PANE_ID, TUIOS_PANE_TTY)을 상속합니다. Ghostty Quick Terminal과 같은 외부 터미널의 대화가 승인을 요청하면, tuios agent-hook codex hook이 해당 이벤트를 최초의 pane에 잘못 귀속시켜 잘못된 사이드바 활동과 macOS 알림이 발생합니다.

수정: PR #882가 포함된 버전으로 TUIOS를 업데이트하세요(v0.10.0 이후 main에 머지됨). 이 수정은 Codex를 shared-server harness로 표시합니다. 같은 서버의 다른 대화는 스레드를 시작하거나 재개할 때만 pane을 점유할 수 있고 턴 도중에는 절대 점유할 수 없으며, 해당 pane의 원래 대화가 다음 리포트 시 pane을 다시 점유하므로 승인이 숨겨지는 일이 없습니다. Compaction은 더 이상 새 대화로 간주되지 않습니다. 다음 릴리스가 배포되면 Homebrew로 업그레이드하거나, 임시 해결책으로 main 브랜치에서 빌드하세요.

Question 5

tuios 키 바인딩이 프랑스어 AZERTY 또는 기타 US가 아닌 키보드 레이아웃에서 잘못된 동작을 트리거하는 이유는 무엇이며, 어떻게 해결할 수 있나요?

Accepted Answer

tuios가 US shifted-digit 별칭(`&` = Shift+7, `(` = Shift+9, `!` = Shift+1)을 전역적으로 적용했기 때문에, `&`, `(`, `!`가 shift 없이 눌리는 키인 AZERTY에서는 `opt+&`가 워크스페이스 1이 아니라 `move_and_follow_7`과 매칭되었고, 별칭이 알파벳 이름 순서에 따라 커스텀 바인딩보다 우선 적용되었습니다. 해결 방법: US 별칭을 별도의 낮은 우선순위 등급으로 이동시켜 `switch_workspace_1 = ['opt+&']`와 같은 명시적 바인딩이 항상 모든 별칭보다 우선하도록 하는 PR #578이 포함된 tuios 빌드로 업그레이드하세요. 하드코딩된 리뷰 오버레이 키 `[ ] { }`에 대한 우회 방법(issue #585에서 추적 중): iTerm2에서 Left Option은 tuios 바인딩용으로 "Esc+"로 설정하고 Right Option은 "Normal"로 설정하면, tuios 바인딩이 계속 작동하는 상태에서 AZERTY로 `[ ] { } |`를 입력할 수 있습니다.

tuios

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트