session log: terminal font investigation (inconclusive)

Appended update to 2026-04-24 session log covering the font change
investigation. Checked bash startup files, Windows Terminal settings,
registry console keys, raw PowerShell output bytes, and installed
fonts. No root cause found — user will report next real-time
occurrence for definitive diagnosis.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-04-24 07:54:33 -07:00
parent 4bec31e226
commit ffe29b286f

View File

@@ -60,3 +60,78 @@ esac
- If either Syncro API key is ever rotated, update the case block in `.claude/commands/syncro.md` and the vault backup - If either Syncro API key is ever rotated, update the case block in `.claude/commands/syncro.md` and the vault backup
- Labor rates should be refreshed from the Syncro products API if pricing changes — endpoint is `GET /products/{id}` - Labor rates should be refreshed from the Syncro products API if pricing changes — endpoint is `GET /products/{id}`
- Travel time ($40) is per-event, not hourly — quantity 1.0 = one trip regardless of duration - Travel time ($40) is per-event, not hourly — quantity 1.0 = one trip regardless of duration
---
## Update: 07:53
### Topic: Terminal Font Investigation
## Session Summary
The session focused on investigating unexpected changes in terminal font behavior when using PowerShell within Windows Terminal. Initial checks included examining bash startup files, which showed no relevant configuration affecting font settings. The Windows Terminal settings.json file was reviewed, revealing no explicit font configuration. Further investigation into the registry and system fonts confirmed that no external font overrides were in place. It was noted that Windows Terminal 1.24 includes Cascadia Mono as a bundled font, which is likely the default used when no other font is specified. Despite these findings, the root cause of the font change remained unclear, prompting the suspension of the investigation pending further real-time reporting from the user.
## Key Decisions
- Decided to inspect both bash and Windows-specific configuration files to ensure no cross-platform misconfigurations were affecting font settings.
- Chose to analyze raw PowerShell output for ANSI escape sequences to rule out potential rendering issues caused by terminal control codes.
- Determined that checking the bundled fonts within Windows Terminal was necessary to identify any implicit font usage when no explicit configuration was present.
## Problems Encountered
- No font-related configuration was found in the user's profile or terminal settings, making it difficult to trace the source of the change.
- The absence of Cascadia fonts in the system fonts directory (only Consolas installed), despite their presence in the Windows Terminal installation, raised questions about font loading behavior.
- Investigation could not conclusively identify the cause of the font change — requires user to report next real-time occurrence for definitive diagnosis.
## Infrastructure / Configuration Examined
- **Windows Terminal settings.json:** `C:\Users\guru\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json`
- Default profile: `{61c54bbd-c2c6-5271-96e7-009a87ff44bf}` (Windows PowerShell)
- `defaults: {}` — no font configured
- No bash/Git Bash profile listed
- **Registry:** `HKCU:\Console`
- `FaceName: __DefaultTTFont__`
- `FontSize: 1048576` (0x00100000)
- `ForceV2: 1` (v2 console host)
- No per-app override key for PowerShell
- **System fonts:** Only Consolas variants installed (no Cascadia as system font)
- **WT bundled fonts:** `C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.24.10921.0_x64__8wekyb3d8bbwe\`
- CascadiaMono.ttf, CascadiaMonoItalic.ttf, CascadiaCode.ttf, CascadiaCodeItalic.ttf
- **Bash startup files checked:** `/etc/profile.d/lang.sh`, `env.sh`, `bash_profile.sh`, `aliases.sh` — no `chcp` calls
## Commands Run
```bash
# Check bash startup for chcp
grep -r "chcp" /etc/profile /etc/profile.d/ ~/.bashrc ~/.bash_profile ~/.profile
# Capture raw PowerShell stdout
powershell.exe -NonInteractive -NoProfile -Command "Write-Host 'test'" | xxd
# Capture raw PowerShell stderr
powershell.exe -NonInteractive -NoProfile -Command "Write-Error 'test'" 2>/tmp/ps_stderr.txt; xxd /tmp/ps_stderr.txt
# Check registry console settings
Get-ItemProperty "HKCU:\Console"
# Check installed fonts
ls /c/Windows/Fonts/ | grep -iE "cascad|consol|caskay|fira|jetbrain"
# Find WT bundled fonts
find "/c/Program Files/WindowsApps/" -maxdepth 2 -name "*.ttf" | grep -i "terminal\|cascad"
```
## Findings
- No ANSI escape sequences in PowerShell stdout or stderr output (plain text + CRLF only)
- No `chcp` calls anywhere in bash startup chain
- Windows Terminal has NO explicit font set — relies on built-in defaults (Cascadia Mono from its own package)
- Cascadia Mono is NOT a system font — loaded only by WT from its WindowsApps package directory
- PowerShell console key does not exist in registry (no per-app override)
## Pending / Next Steps
- **Font issue: UNRESOLVED** — root cause not identified
- User will report next occurrence in real time
- On report: immediately capture `HKCU:\Console` state, recent process stdout raw bytes, and what command just ran
- Possible remaining suspects: VT escape sequences leaking through ConPTY, WT profile switching, Win32 `SetCurrentConsoleFontEx` call honored by WT in some edge case