diff --git a/.claude/memory/MEMORY.md b/.claude/memory/MEMORY.md index 45b20e48..4c9e1a8c 100644 --- a/.claude/memory/MEMORY.md +++ b/.claude/memory/MEMORY.md @@ -211,3 +211,4 @@ - [ScreenConnect custom-property slots](reference_screenconnect_custom_property_slots.md) — CP1=Company CP2=Site CP3=Department CP4=Device Type CP8=Tag (API hides labels; UpdateSessionCustomProperties replaces the whole array) - [ScreenConnect cleanup uses wiki as source](feedback_screenconnect_cleanup_wiki_source.md) — per-client SC/RMM metadata cleanup pulls machine->dept/location from the client wiki; enrich the wiki when missing - [TECH03L systemprofile shortcut corruption](project_tech03l_systemprofile_shortcut_corruption.md) — Auto-Claude "opens then closes" = .lnk pointing at nonexistent systemprofile path; repoint, do not debug the app +- [Claude tui fullscreen crash](feedback_claude_tui_fullscreen_crash.md) — "flicker-free" prompt writes tui=fullscreen; instant-exit crash loop on some Windows terminals; set tui=default (reinstall does NOT fix) diff --git a/.claude/memory/feedback_claude_tui_fullscreen_crash.md b/.claude/memory/feedback_claude_tui_fullscreen_crash.md new file mode 100644 index 00000000..346119de --- /dev/null +++ b/.claude/memory/feedback_claude_tui_fullscreen_crash.md @@ -0,0 +1,22 @@ +--- +name: claude-tui-fullscreen-crash +description: Claude Code "flicker-free rendering" prompt writes tui=fullscreen to settings.json and can crash-loop the CLI on Windows; fix = delete the tui key +metadata: + type: feedback +--- + +On ACG-TECH03L (2026-07-04, Claude Code 2.1.201), accepting the startup prompt asking to +enable **flicker-free rendering** wrote `"tui": "fullscreen"` into +`~/.claude/settings.json`. On that machine's terminal the fullscreen/alternate-screen +mode crashed the CLI instantly on every subsequent launch ("opens and then closes") — +from any launch path, since all read the same settings file. + +**Why:** the setting persists, so one bad answer to the prompt turns into a permanent +crash loop; reinstalling Claude Code does NOT fix it because settings survive reinstall. + +**How to apply:** if a fleet machine's Claude Code exits immediately at launch, check +`~/.claude/settings.json` for `"tui": "fullscreen"` and set it to `"tui": "default"` +(surgically — keep hooks/plugins; explicit "default" also suppresses re-prompting, +which deleting the key does not). Emergency override without touching config: +`CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1`. Decline the flicker-free prompt on machines +with older terminals/conhost. Related: [[tech03l-systemprofile-shortcut-corruption]]. diff --git a/errorlog.md b/errorlog.md index 644cf5df..41e8a3a7 100644 --- a/errorlog.md +++ b/errorlog.md @@ -19,6 +19,8 @@ Categories (the `[type]` tag): _(none)_ = skill/command execution failure · +2026-07-04 | Howard-Home | bash/quoting | [friction] inline PS-in-bash heredoc with nested quotes mangled by CommandLineToArgvW on dispatch to RMM; fixed by file+EncodedCommand path [ctx: ref=feedback_windows_quote_stripping] + 2026-07-04 | Howard-Home | rmm/claude-reinstall | fresh claude-code 2.1.201 npm install on ACG-Tech03L crashed 0xC0000005 on first --version run, succeeded on retry; suspected Datto EDR first-touch scan of new binaries [ctx: machine=ACG-Tech03L cmd=9770a7af] 2026-07-04 | Howard-Home | rmm/ps-encoded | ps-encoded.sh failed on Howard-Home: iconv not found in Git Bash; fell back to powershell.exe base64 encoding [ctx: machine=Howard-Home script=.claude/scripts/ps-encoded.sh] diff --git a/wiki/clients/dataforth.md b/wiki/clients/dataforth.md index cbf83a76..df68fc93 100644 --- a/wiki/clients/dataforth.md +++ b/wiki/clients/dataforth.md @@ -137,7 +137,7 @@ Signal conditioning / data acquisition manufacturer in Tucson, AZ. Long-standing | ESXi hosts | 192.168.0.122, 192.168.0.124 | VMware ESXi hypervisors | ESXi | — | | UDM Firewall | 192.168.0.254 | Perimeter firewall/router | UniFi OS 5.1.15 | MAC d0:21:f9:6c:11:02. Also responds on 192.168.0.1. SSH: `azcomputerguru@192.168.0.254`, root SSH key added 2026-06-08, 2FA push required. Vault: `clients/dataforth/udm.sops.yaml`. C2 IPs blocked via iptables (NOT permanent — need to add to UniFi UI). Boot scripts in `/data/on_boot.d/`: `10-neptune-snat.sh` (Neptune outbound SNAT), `30-freepbx-sip-forward.sh` (SIP DNAT, WAN UDP 5060 source-locked to 66.7.123.0/24 → 192.168.100.2; SIP-only — do NOT add RTP forward). **[WARNING] Confirmed 2026-06-23: the SIP DNAT rule can be silently flushed by a UniFi controller provision/update, not only a reboot** — the on_boot.d script only re-applies at boot, so a mid-uptime provision event leaves inbound calls dead until the script is manually re-run. Recommend adding a persistent UI port-forward rule as a belt-and-suspenders measure (still not done as of 2026-07-04). | | PBX (Sangoma FreePBX) | 192.168.100.2 | VoIP PBX — production phones on 192.168.100.0/24 | Sangoma FreePBX 17 / Asterisk 22.5.2, Debian 12 | FirstDigital PJSIP trunk; SBC 66.7.123.215:5060 (Sonus), match 66.7.123.0/24; IP-auth (no registration). `qualify_frequency=0` (FD SBC ignores OPTIONS — do NOT revert). TFTP provisioning for Cisco SPA502G phones. Extensions 201-343. SSH: `sangoma@192.168.100.2` (ACG SSH key also authenticates). Vault: `clients/dataforth/pbx.sops.yaml` — password corrected 2026-06-23 (prior entry had a backslash-escaping corruption in the stored value; re-verify the vault entry byte-for-byte before use rather than assuming it is stale). [WARNING] Re-apply `PJSip.class.php` line-504 patch after any `fwconsole ma updateall`. **NOTE:** `sangoma` user is in the `sudo` group but sudo authorization on this box appears not actually granted — verify before assuming privileged ops will work via sudo. | -| **MYDATA TPSys SMT Controller** (`myserver`) | 192.168.1.x (verify — exact IP unconfirmed) | MYDATA/Mycronic TPSys pick-and-place SMT production-line controller | Fedora Core 3 "Heidelberg" (Nov 2004), kernel 2.6.16.20, glibc ~2.3.5, bash 3.00, **LILO** bootloader, **SysV init** (no systemd) | **NEW, discovered 2026-07-04.** On VLAN 2 "mydata" (192.168.1.0/24, gateway 192.168.1.1). TPSys operator UI runs under X (runlevel 5); local PostgreSQL (uid 500) backs TPSys. Accounts: `root`, `tpsys` (TPSys app user), `tpspool` (TPSys spool), `postgres`. **No credential existed anywhere (vault or wiki) prior to this discovery** — root password was RESET via physical-console LILO recovery (no prior password to lose) and is now vaulted at `clients/dataforth/mydata-smt.sops.yaml` (reference the vault path only; never the raw password). `tpsys` being added to the `wheel` group plus a scoped `NOPASSWD` sudoers entry for the app-launch command (directed, not yet verified as landed). **GuruRMM agent CANNOT run on this box** — see Patterns below. | +| **MYDATA TPSys SMT Controller** (`myserver`) | **192.168.1.1** (confirmed 2026-07-04) | MYDATA/Mycronic TPSys pick-and-place SMT production-line controller | Fedora Core 3 "Heidelberg" (Nov 2004), kernel 2.6.16.20, glibc ~2.3.5, bash 3.00, **LILO** bootloader, **SysV init** (no systemd) | **NEW, discovered 2026-07-04.** On VLAN 2 "mydata" (192.168.1.0/24). **[WARNING] Its IP 192.168.1.1 collides with the address previously recorded as the VLAN 2 gateway — reconcile: either this box IS the gateway/router for the SMT line, or there is an IP conflict with the UDM. Confirm before relying on either.** TPSys operator UI runs under X (runlevel 5); local PostgreSQL (uid 500) backs TPSys. Accounts: `root`, `tpsys` (TPSys app user), `tpspool` (TPSys spool), `postgres`. **No credential existed anywhere (vault or wiki) prior to this discovery** — root password was RESET via physical-console LILO recovery (no prior password to lose) and is now vaulted at `clients/dataforth/mydata-smt.sops.yaml` (reference the vault path only; never the raw password). `tpsys` being added to the `wheel` group plus a scoped `NOPASSWD` sudoers entry for the app-launch command (directed, not yet verified as landed). **GuruRMM agent CANNOT run on this box** — see Patterns below. | TPSys operator UI runs under X (runlevel 5); local PostgreSQL (uid 500) backs TPSys. Accounts: `root`, `tpsys` (TPSys app user), `tpspool` (TPSys spool), `postgres`. **No credential existed anywhere (vault or wiki) prior to this discovery** — root password was RESET via physical-console LILO recovery (no prior password to lose) and is now vaulted at `clients/dataforth/mydata-smt.sops.yaml` (reference the vault path only; never the raw password). `tpsys` being added to the `wheel` group plus a scoped `NOPASSWD` sudoers entry for the app-launch command (directed, not yet verified as landed). **GuruRMM agent CANNOT run on this box** — see Patterns below. | **Neptune Exchange (ACG infrastructure, physically at Dataforth D2):** - `neptune.acghosting.com` | internal `172.16.3.11` | external inbound `67.206.163.124` / outbound `67.206.163.122` @@ -491,7 +491,7 @@ As of 2026-07-04 (0 open Syncro tickets per live pull): - **DOS Test Station Data Pipeline (Syncro #32489, active):** Root cause confirmed 2026-07-01 via a read-only ground-truth audit run through a headless Claude spawned on AD2's GuruRMM agent (new capability — see [RMM-Spawned Claude](#rmm-spawned-claude-on-ad2)). F1 (NWTOC v5.0 never copies master `.DAT` specs to stations) is confirmed; F2 (`COPY /Y` may not be valid on true MS-DOS 6.22) needs a station-side check before scoping the fix. **Next steps:** (1) confirm station DOS version (`VER` + `COPY /Y NUL C:\TEST.TXT` on a station), (2) draft a DOS-6.22-safe `NWTOC v5.1` that adds a one-way pull of master `.DAT`s (plain `COPY`, no `/Y` if 6.22 confirmed) without reintroducing the cyclic-overwrite problem v5.0 was avoiding, (3) Grok-review the new script before it touches a station, (4) update ticket #32489 with the confirmed root cause and plan. Secondary cleanup items from the same audit (not urgent): remove the stray `TS-21\ProdSW` file (F3), feed `testdatadb\specdata\` from live engineering masters (F4), rotate/vault the plaintext creds found in scripts (F5), retire dead `For_Web` output and abandoned v1.x script drafts (F6/F7/F8). -- **MYDATA TPSys SMT controller (new, discovered 2026-07-04):** Root password reset via LILO recovery and **vaulted 2026-07-04** at `clients/dataforth/mydata-smt.sops.yaml` (host/VLAN/OS/accounts/recovery-method documented; decrypt-verified). **Outstanding:** (1) confirm the machine's exact IP on 192.168.1.x and reconcile against the known mydata VLAN member list; (2) verify the `tpsys` wheel-group + scoped `NOPASSWD` sudoers change actually landed (`id tpsys`, `sudo -l` as tpsys); (3) get the exact TPSys app-launch command from Howard/Mike to finalize the sudoers scope; (4) confirm the controller booted cleanly into TPSys after the forced reboot (it is a live production SMT line); (5) decide and stand up agentless monitoring (ICMP/TCP probe or SSH heartbeat from D2TESTNAS or the RMM server — inter-VLAN routing to mydata is open) since a GuruRMM agent is impossible on this OS; formalize via `/feature-request` if Mike wants legacy/appliance Linux monitoring as a standing GuruRMM capability. +- **MYDATA TPSys SMT controller (new, discovered 2026-07-04):** Root password reset via LILO recovery and **vaulted 2026-07-04** at `clients/dataforth/mydata-smt.sops.yaml` (host/VLAN/OS/accounts/recovery-method documented; decrypt-verified). **Outstanding:** (1) **IP confirmed 192.168.1.1 (2026-07-04) — but this collides with the recorded VLAN 2 gateway; reconcile whether this box is the SMT-line gateway/router or there is an IP conflict with the UDM;** (2) verify the `tpsys` wheel-group + scoped `NOPASSWD` sudoers change actually landed (`id tpsys`, `sudo -l` as tpsys); (3) get the exact TPSys app-launch command from Howard/Mike to finalize the sudoers scope; (4) confirm the controller booted cleanly into TPSys after the forced reboot (it is a live production SMT line); (5) decide and stand up agentless monitoring (ICMP/TCP probe or SSH heartbeat from D2TESTNAS or the RMM server — inter-VLAN routing to mydata is open) since a GuruRMM agent is impossible on this OS; formalize via `/feature-request` if Mike wants legacy/appliance Linux monitoring as a standing GuruRMM capability. - **DFORTH-Ship BSOD (ongoing monitoring):** Edge hardware-acceleration mitigation applied 2026-06-25; needs on-site Edge restart/reboot to take effect, verify at `edge://policy`. Monitor for recurrence — if it bugchecks again, pull and analyze the four older dump signatures to confirm whether it is drifting toward a hard hardware fault. Schedule thermal cleaning of the USDT chassis. Recommend/plan replacement of the 11.5-year-old EliteDesk 800 G1 USDT shipping station as the durable fix.