fix: redact remaining personal identifiers in hpc, wezterm, sway, and email.service

[stanfish06]

Closes #77
Closes #78
Closes #80

PR #79 was closed without merging. Issues #77 and #78 remain open. This PR re-applies those fixes and also addresses the newly-found #80 (wezterm background path).

Changes

1. hpc/monitor_job.sh — use $USER instead of zyyu (issue #77)

-  for jobid in $(squeue -u zyyu -h -o "%i"); do
+  for jobid in $(squeue -u "$USER" -h -o "%i"); do

2. wezterm/.wezterm.lua — three redactions

issue #77 — HPC username in ssh_domains and launch_menu:

-    username = "zyyu",
+    username = "username",
...
-        args = { "ssh", "zyyu@greatlakes.arc-ts.umich.edu" },
+        args = { "ssh", "username@greatlakes.arc-ts.umich.edu" },

issue #80 — personal Windows username zhiyu in background image path:

-    { source = { File = "C:/Users/zhiyu/Desktop/Git/my-configs/img/dark-green-forest.jpg" }, opacity = 0.4 },
+    { source = { File = wezterm.home_dir .. "/.config/wezterm/background.jpg" }, opacity = 0.4 },

Wire up at deploy time:

New-Item -ItemType SymbolicLink -Path "$env:USERPROFILE\.config\wezterm\background.jpg" -Target "$env:USERPROFILE\Desktop\Git\my-configs\img\dark-green-forest.jpg"

3. sway/40-sway-background.conf — stable wallpaper path (issue #78)

-output * bg /home/stanfish/Git/my-configs/img/space.jpeg fill
+output * bg ~/.config/sway/wallpaper.jpeg fill

Wire up at deploy time:

ln -sf ~/Git/my-configs/img/space.jpeg ~/.config/sway/wallpaper.jpeg

4. linux/services/email.service — use %h specifier (issue #78)

-User=stanfish
-ExecStart=/home/stanfish/scripts/system/fetch-emails.sh
+# User=  # set locally: User=your-username
+ExecStart=%h/scripts/system/fetch-emails.sh

Test plan

• grep -r 'zyyu\|zyu14' hpc/monitor_job.sh wezterm/ — no matches
• grep -r 'zhiyu\|Users/' wezterm/ — no matches
• grep -r 'home/stanfish' sway/ linux/services/ — no matches
• monitor_job.sh on HPC lists current user's jobs
• Sway starts with wallpaper after symlinking ~/.config/sway/wallpaper.jpeg
• WezTerm starts with background after symlinking ~/.config/wezterm/background.jpg

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5d83fdc864

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Restore explicit User= for email service

Removing User= from this system unit makes the service run as root by default and changes %h in ExecStart to root’s home, so it tries to execute /root/scripts/system/fetch-emails.sh instead of the intended unprivileged user script path. In this repo state, systemd-analyze verify linux/services/email.service already resolves the command to /root/... and reports it missing, so the service fails unless each machine patches the unit locally and otherwise runs with elevated privileges.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Avoid hard-coding placeholder SSH username

Setting the SSH user to the literal string "username" breaks the WezTerm Great Lakes shortcut for any account that is not actually named username; both ssh_domains and the launch menu now target the wrong remote user and will fail authentication in normal setups. This redaction should use a dynamic value (or omit the user so SSH picks the local default) rather than a fixed placeholder.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Stop using %h in this system unit ExecStart

%h in a system service does not follow the runtime User= expectation here and resolves to the system manager’s home (/root), so even after following the inline comment and setting User=your-username, ExecStart=%h/scripts/system/fetch-emails.sh still points at /root/scripts/... and won’t run the intended per-user script. A local repro with systemd-analyze verify on a test unit with User=nobody resolves %h to /root, confirming this path strategy is incorrect for this unit type.

Useful? React with 👍 / 👎.