My Codex CLI sometimes paused for about five seconds when it started. Other launches were almost immediate. After checking the proxy setup, I looked at the startup logs. They showed a model-list request consuming five seconds before timing out.

Three Codex versions were sharing the same model cache. A cache written by one version could be rejected by another, which forced another network request. I aligned the CLI with the shared server and changed the desktop launcher to use the same CLI on its next launch. Five subsequent terminal checks reached the model and prompt in a median of 0.80 seconds.

Update 2026-11-06: a later startup investigation found a separate delay. Different Codex versions rejected each other’s shared model cache and triggered model-list refreshes that timed out after five seconds. See Codex startup and the shared model cache.

My XPS uses lfang.idc as a proxy gateway. v2rayA runs on the IDC host, and applications on XPS connect to the gateway over the private network. Codex needs one extra check: its shared app-server daemon keeps the environment it received when it started.

I keep Claude Code in a tmux pane above a zsh pane, so its status line sits just above my zsh prompt, and the two almost matched. Both used the same powerlevel10k colours and separators, but Claude’s line started 2 columns further in and stopped wherever its text ran out. The zsh line ran the full width of the terminal, so the pair looked misaligned.

The fix was a dotted gap computed from $COLUMNS and "padding": -2, a value the docs don’t mention. Now both prompts start at column 0 and close on the same column, 134 of 135.

https://account.apple.com/ https://account.apple.com/sign-in: 右上角"城建你的 Apple 账户" 使用美国或者日本账户: 可以填写中国的,只是作为验证,不会要求美国

My team’s internal portal runs on plain http on the LAN, at http://192.168.1.82:8888. I wanted its note editor to grab a screenshot of another window straight from the browser, Flameshot-style, with getDisplayMedia(). On that address the API isn’t there at all: browsers only offer screen capture in a secure context, and an http page on a LAN IP is not one.

The fix is https next to http, with a certificate signed by a small local CA that each computer trusts once. My first attempt, the usual one-line self-signed openssl req -x509, made the wrong kind of certificate: a CA certificate with no serverAuth usage, which Apple’s rules reject.

After the startup pass, the slowest thing left in my Neovim was big log files. ~/log holds logs from 0.5 MB to 136 MB. The one I read most is 87 MB: 176,939 lines of about 500 characters, growing by about 2 lines a second while I read it. Opening it took 1.9 s before Neovim accepted a key. n, /, typing and <Esc> each stalled. Just reading the log while it grew froze the UI for about 11 of every 15 seconds.

No single plugin was to blame. Several separate pieces of work grew with the file, and one key mapping slowed n in every file. Medians of 5 runs in a real terminal:

	before	after
open the 87 MB log until keys are accepted	1857 ms	199 ms
n	523 ms	21 ms
UI blocked per 15 s while reading the growing log	10963 ms	0 ms