Background
Many CLI tests use `monkeypatch.setenv("HOME", str(tmp_path))` to isolate `~/.memtomem/` writes from the developer's real home. On Windows, `Path.home()` consults `USERPROFILE` (then `HOMEDRIVE`+`HOMEPATH`), so the HOME monkeypatch is silently ignored — tests write into / read from the actual runner home (`C:\Users\runneradmin\.memtomem\`).
This appears to be the largest single category of Windows failures from PR #638's matrix run (~30+ tests across multiple files).
Symptoms
- Tests that assert state file existence under `tmp_path / ".memtomem"` fail because the file landed at the real home
- Cross-test bleed: state from `test_A` (writing to real home) breaks `test_B`'s "no config" precondition (e.g., `TestRequireConfigured` 409→200 mismatches in `test_web_routes.py`)
- Path mismatches in error messages
Affected files (estimated)
- `packages/memtomem/tests/test_init_cmd.py` — 23 failures
- `packages/memtomem/tests/test_uninstall_cmd.py` — 12 failures
- `packages/memtomem/tests/test_upgrade_cmd.py` — 4 failures
- `packages/memtomem/tests/test_web_routes.py::TestRequireConfigured` — config-gate failures
- Subset of: `test_config_overrides.py`, `test_context_status.py`, `test_dirty.py`
Fix patterns
Per-test: monkeypatch both `HOME` and `USERPROFILE` (or whichever `Path.home()` reads on the current platform):
```python
home_var = "USERPROFILE" if sys.platform == "win32" else "HOME"
monkeypatch.setenv(home_var, str(tmp_path))
```
Centralized: introduce a `monkeypatched_home(monkeypatch, tmp_path)` helper in `tests/helpers.py` so the platform branching lives in one place and tests just call `monkeypatched_home(monkeypatch, tmp_path)`. Audit all current `monkeypatch.setenv("HOME", ...)` sites and migrate.
Production code: confirm `Path.home()` is the only consumer; if any CLI code reads `os.environ["HOME"]` directly, that path is also broken on Windows.
Refs
🤖 Generated with Claude Code
Background
Many CLI tests use `monkeypatch.setenv("HOME", str(tmp_path))` to isolate `~/.memtomem/` writes from the developer's real home. On Windows, `Path.home()` consults `USERPROFILE` (then `HOMEDRIVE`+`HOMEPATH`), so the HOME monkeypatch is silently ignored — tests write into / read from the actual runner home (`C:\Users\runneradmin\.memtomem\`).
This appears to be the largest single category of Windows failures from PR #638's matrix run (~30+ tests across multiple files).
Symptoms
Affected files (estimated)
Fix patterns
Per-test: monkeypatch both `HOME` and `USERPROFILE` (or whichever `Path.home()` reads on the current platform):
```python
home_var = "USERPROFILE" if sys.platform == "win32" else "HOME"
monkeypatch.setenv(home_var, str(tmp_path))
```
Centralized: introduce a `monkeypatched_home(monkeypatch, tmp_path)` helper in `tests/helpers.py` so the platform branching lives in one place and tests just call `monkeypatched_home(monkeypatch, tmp_path)`. Audit all current `monkeypatch.setenv("HOME", ...)` sites and migrate.
Production code: confirm `Path.home()` is the only consumer; if any CLI code reads `os.environ["HOME"]` directly, that path is also broken on Windows.
Refs
🤖 Generated with Claude Code