Scribbles for my memory

WezTerm binds Alt+Enter to toggle fullscreen by default. That hijacks Alt+Enter newline in Claude Code, GitHub Copilot, and other terminal-based tools.

Drop this in ~/.wezterm.lua to disable the default and remap fullscreen to Ctrl+Shift+F11:

local wezterm = require 'wezterm'
local config = wezterm.config_builder()

config.keys = {
  {
    key = 'Enter',
    mods = 'ALT',
    action = wezterm.action.DisableDefaultAssignment,
  },
  {
    key = 'F11',
    mods = 'CTRL|SHIFT',
    action = wezterm.action.ToggleFullScreen,
  },
}

return config

Config takes effect immediately on save — no restart needed.

If you've been alt-tabbing to an admin cmd window to run mklink every time you wanted a symlink on Windows, there's a much cleaner way nobody seems to mention. Two settings, set them once, forget about it.

The reason ln -s in git-bash silently turns into cp by default is two unrelated barriers stacked together:

1. Windows non-admins can't create symlinks unless Developer Mode is on.
2. MSYS (git-bash's runtime) doesn't even try to create native symlinks without the MSYS env var set.

Fix the first once with admin, fix the second in your shell profile.

# Run once in admin PowerShell, or use Settings → Update & Security → For developers → Developer Mode
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" `
  -Name "AllowDevelopmentWithoutDevLicense" -Value 1 -Type DWord

# In ~/.bashrc
export MSYS=winsymlinks:nativestrict

nativestrict makes failures loud — ln -s errors out instead of silently copying when symlinks aren't supported. Avoid winsymlinks:native (the lenient sibling) — its silent fallback is exactly the trap you're trying to escape. Avoid winsymlinks:lnk entirely; .lnk shortcuts aren't symlinks anything else recognizes.

Open a new git-bash window and verify:

ln -s ~/.bashrc /tmp/test-link
ls -la /tmp/test-link

If the line starts with l, it's a real symlink that git, Linux tools, GNU stow, and your dotfiles install.sh all treat consistently across platforms. If it starts with -, either the env var didn't reach the new shell or Developer Mode didn't actually toggle.

Bonus: Developer Mode also unlocks Windows 11's native sudo command, so you can stop alt-tabbing to admin terminals for quick one-offs entirely.

Your Windows Terminal default tab is opening with admin privileges and you don't remember asking for it. The intuitive guess is the AppCompat Layers registry — that's where ticking "Run as administrator" on a shortcut's compatibility tab gets stored, and it persists across reinstalls. Worth checking, but it's the second place to look for WT.

The first place is settings.json:

{
    "commandline": "C:\\Program Files\\Git\\bin\\bash.exe",
    "elevate": true,
    "guid": "{17c3a2bf-...}",
    "name": "Git Bash"
}

WT 1.18+ added elevate as a per-profile flag. When it's true and that profile is also pointed to by defaultProfile, every new window silently opens elevated — no UAC prompt at the tab level because the elevation happened at WT launch. Delete the line, restart WT, done.

If you still want an admin tab on demand, add a second profile with a fresh GUID and a different name (e.g. "Git Bash (Admin)") that keeps elevate: true. You get a dropdown choice and a real UAC prompt when you actually need it, instead of unconditional elevation on every launch.

To rule out the registry side as well:

Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"
Get-ItemProperty -Path "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"

Each property name is an exe path; a value containing RUNASADMIN means that program is forced to elevate every launch. To clear one, prefer the GUI — right-click the exe → Properties → Compatibility → uncheck "Run this program as administrator" — over editing the registry by hand.

Two mechanisms, same symptom, different layers. For Windows Terminal specifically, the per-profile setting wins; check it first.

AWS console offers three ways to duplicate an EC2 instance, differing in whether disk data is carried over.

Create AMI (recommended, full clone) — preserves the system disk, installed software, and all configuration.

In the EC2 console, select the target instance → Actions → Image and templates → Create image. Wait for the AMI status to become available (a few minutes to tens of minutes), then go to AMIs → select it → Launch instance from AMI. Adjust instance type, subnet, Security Group as needed.

Launch More Like This (fastest, no data) — copies only instance configuration (type, SG, subnet, tags). The system disk is brand new.

Actions → Image and templates → Launch more like this. The Launch page opens with config pre-filled; confirm and launch. Good for stateless instances, e.g. web servers initialized via userdata.

Launch Template — if the original instance had a Launch Template saved, launch directly from it. EC2 → Launch Templates → select template → Actions → Launch instance from template.

Use AMI for most cases. Use Launch More Like This when you only need the same specs with a clean disk.

AWS 控制台里有三种复制 EC2 的方式，区别在于是否携带磁盘数据。

创建 AMI（推荐，完整克隆） — 保留系统盘数据、已安装软件和所有配置。

EC2 控制台选中目标实例 → Actions → Image and templates → Create image。等 AMI 状态变为 available（几分钟到几十分钟），再到 AMIs 页面选中它 → Launch instance from AMI，按需调整 instance type、subnet、Security Group 即可。

Launch More Like This（最快，但不含数据） — 只复制实例规格配置（type、SG、subnet、tags），系统盘是全新的。

Actions → Image and templates → Launch more like this，进入 Launch 页面时配置已预填好，确认启动就行。适合无状态实例，比如用 userdata 初始化的 web server。

Launch Template — 如果原实例之前保存过 Launch Template，可以直接从模板启动。EC2 → Launch Templates → 选模板 → Actions → Launch instance from template。

大多数场景用 AMI，只需要同规格全新系统时用 Launch More Like This。