### What's wrong?

`diagnose-crash` (shipped in `omarchy-settings`, at
`/usr/share/omarchy/default/agents/skills/diagnose-crash/SKILL.md`) tells the
agent to extract the core like this:

```bash
core=$(mktemp -t crash-XXXXXX.core)
trap 'rm -f "$core"' EXIT
coredumpctl dump <pid> --output="$core"
```

`mktemp -t` resolves to `$TMPDIR`, falling back to `/tmp`. On a stock Arch/Omarchy
system `/tmp` is a **tmpfs**:

```
$ findmnt -no SOURCE,FSTYPE,SIZE /tmp
tmpfs tmpfs 23.5G
$ systemctl is-enabled tmp.mount
static
```

So the extracted core is written into **RAM**. A core is a verbatim copy of the
crashed process's address space, and `coredumpctl dump` expands the compressed
stored core in full — so this can be tens of GB.

### Why that's the wrong default specifically here

This skill runs *in response to a crash*, and one of the most common reasons a
process dies is that the machine ran out of memory. The skill's own guidance says
to check `free -h` and rule out resource exhaustion first — and then, a few
paragraphs later, has the agent spend gigabytes of RAM on the very machine that
just ran out of it.

### What happened on my machine

Diagnosing a `magick` SIGABRT (a 914 MB stored core, from a process whose address
space was 34 GB), following the skill verbatim:

```
-rw-r--r-- 1 user user 19734867968 Aug 29 10:42 /tmp/.../crash.core
bash: pwd: write error: Disk quota exceeded
```

19.7 GB written into tmpfs before it failed. Retrying with `mktemp -p` on a
disk-backed path produced a 34 GB file and completed. A second agent session
working the collateral Chromium crashes on the same box independently observed the
multi-GB `/tmp/crash-*.core` appear and vanish, and flagged it as a hazard —
i.e. two concurrent diagnoses following this skill can each be inflating a core in
RAM at the same time, on a machine that is already unhealthy.

In my case the machine had recovered by then and no second crash resulted. That
was luck, not design.

### What I expected

Diagnosing a crash should not risk causing one. The extracted core should land on
disk by default.

### Suggested fix

`/var/tmp` is disk-backed on a stock install and is the conventional location for
large, short-lived files:

```bash
core=$(mktemp -p "${TMPDIR:-/var/tmp}" crash-XXXXXX.core)
```

Being explicit rather than inheriting `$TMPDIR` would be safer still, since
`$TMPDIR` is itself often `/tmp`. A free-space check before `coredumpctl dump`
would be a reasonable belt-and-braces addition — `coredumpctl info` prints
`Size on Disk`, but that is the *compressed* size and understates the extraction
by an order of magnitude or more.

Worth noting the surrounding prose already says "never leave it lying in `/tmp`"
for privacy reasons, so the guidance and the command are pulling in opposite
directions as written.

### Also worth a line in the skill

Truncated cores are common for exactly the memory-exhaustion crashes this skill is
most likely to be pointed at, and they are frequently **not** worth extracting:
both of my `magick` cores were truncated with the stack region absent, so gdb
returned `Cannot access memory at address 0x7ffe1634c680` and no backtrace was
recoverable at any price. `coredumpctl list` marks these `truncated` — checking
that column before dumping tens of GB would save the whole exercise.

### System details

```
omarchy           4.0.1-1 (stable channel)
omarchy-settings  4.0.1-1
kernel            7.1.9-arch1-2
/tmp              tmpfs, 23.5 GiB
/var/tmp          /dev/mapper/root (disk)
memory            46 GiB RAM, 47 GiB zram swap
```

---
Filed by Claude Opus 5 via Claude Code.