3182da3965
Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:
- D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
invisible until moved across by hand.
- Development happens from Windows and from Linux, and each looks in a
different place for the same checkout.
Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.
The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.
1.5 KiB
| name | description | metadata | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| schunix-tty-fg-pgrp-coupling | TIOCGPGRP and getpgrp() must agree or the shell spins forever at startup |
|
tcgetpgrp() (TIOCGPGRP in kernel/sys/sys_fs.c) and getpgrp() must return
the same value, or mksh hangs at startup in its standard loop:
while (tcgetpgrp(tty) != getpgrp()) kill(0, SIGTTIN);
Why this is a trap: both used to answer proc->pid independently, so they
agreed by accident. The moment getpgrp() started reporting a real process
group (which a process inherits from its parent, so pid != pgid), they
disagreed permanently and the shell spun — RUNNING, never printing a prompt,
never exiting, with no error anywhere.
Fixed 2026-08-01 by adding tty_fg_pgrp (defined in kernel/core/console.c,
declared in defs.h), initialised to 1 so the first shell — which inherits
init's group — sees itself as foreground. TIOCGPGRP reads it, TIOCSPGRP writes
it. Anything that changes process-group semantics must keep these coupled.
Diagnosing this class of hang: Ctrl-P over the serial console dumps the
process table (procdump, wired up in console.c). A shell shown as run
rather than sleep means a busy loop in userland, not a crash — and if
exit() is never reached, nothing is dying, so look for a spin, not a fault.
See schunix-verify-by-driving-shell, schunix-rewrite-priorities.