aterm: windows the macOS bundles open show "kitty" rather than the branded title #1292

New issue

Closed

opened 2026-08-27 03:01:03 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-27 03:01:03 +00:00

Owner

Kai reports that terminals started by the ~/Applications bundles carry only kitty as their title.

What I established, all measured on kais-macbook-pro with kitty 0.48.2 and aos-v0.249.0:

The bundle environment computes the right title. Replaying the wrapper's exact env (baked PATH, AGENT_COMPOSE_BIN, AOS_BIN, ATERM_TERMINAL_BIN) with --dry-run --json gives brand.title = projects // Agentic Platform Engineer // ⛏️ 🪨 Angie [she] // acting, workspace projects, executable /opt/homebrew/bin/kitty. So aterm passes --title on this path exactly as it does from a shell.
/opt/homebrew/bin/kitty is a cask wrapper that execs /Applications/kitty.app/Contents/MacOS/kitty "$@", so the two launch paths reach the same binary with the same argv. spawnWindow execs it directly, no open -a.
A child that emits OSC 2 overrides --title in kitty 0.48.2. Probe: kitty --title X ... sh -c 'printf "\033]2;CHILD-SET\007"; sleep' reports tab and window title CHILD-SET. The comment in aterm/plan.go ("kitty's --title permanently fixes the OS window title against the child") no longer matches kitty's behavior, whatever kitty --help still claims.
What the titlebar actually displays is not observable from an agent session. kitty @ ls exposes wm_name/wm_class (both kitty on macOS) and the raw child title, never the rendered one. System Events needs assistive access, Quartz is absent from the system python, and lsappinfo info -app <pid> returns LSDisplayName=kitty, the LaunchServices app name rather than a window title.

Open question that decides the fix, and needs eyes on a screen: whether kitty is the titlebar text or the app label macOS shows in the Dock, the switcher, and Mission Control. The bundles are LSUIElement, so the window's Dock tile belongs to kitty.app and is labeled kitty with kitty's icon for every role, which is expected under the current design and would need a per-bundle app identity to change. A titlebar showing kitty is a different defect, and the OSC 2 finding above is the likely mechanism.

Kai reports that terminals started by the `~/Applications` bundles carry only `kitty` as their title. What I established, all measured on kais-macbook-pro with kitty 0.48.2 and aos-v0.249.0: - The bundle environment computes the right title. Replaying the wrapper's exact env (baked PATH, `AGENT_COMPOSE_BIN`, `AOS_BIN`, `ATERM_TERMINAL_BIN`) with `--dry-run --json` gives `brand.title` = `projects // Agentic Platform Engineer // ⛏️ 🪨 Angie [she] // acting`, workspace `projects`, executable `/opt/homebrew/bin/kitty`. So aterm passes `--title` on this path exactly as it does from a shell. - `/opt/homebrew/bin/kitty` is a cask wrapper that `exec`s `/Applications/kitty.app/Contents/MacOS/kitty "$@"`, so the two launch paths reach the same binary with the same argv. `spawnWindow` execs it directly, no `open -a`. - A child that emits `OSC 2` overrides `--title` in kitty 0.48.2. Probe: `kitty --title X ... sh -c 'printf "\033]2;CHILD-SET\007"; sleep'` reports tab and window title `CHILD-SET`. The comment in `aterm/plan.go` ("kitty's --title permanently fixes the OS window title against the child") no longer matches kitty's behavior, whatever `kitty --help` still claims. - What the titlebar actually displays is not observable from an agent session. `kitty @ ls` exposes `wm_name`/`wm_class` (both `kitty` on macOS) and the raw child title, never the rendered one. `System Events` needs assistive access, `Quartz` is absent from the system python, and `lsappinfo info -app <pid>` returns `LSDisplayName=kitty`, the LaunchServices app name rather than a window title. Open question that decides the fix, and needs eyes on a screen: whether `kitty` is the titlebar text or the app label macOS shows in the Dock, the switcher, and Mission Control. The bundles are `LSUIElement`, so the window's Dock tile belongs to kitty.app and is labeled `kitty` with kitty's icon for every role, which is expected under the current design and would need a per-bundle app identity to change. A titlebar showing `kitty` is a different defect, and the OSC 2 finding above is the likely mechanism.

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-27 03:31:01 +00:00

fix(aterm): give each role bundle the window it opens #1304

coilyco-ops closed this issue

2026-08-27 03:34:46 +00:00