Is this a reproducible bug?
Current behavior
I am running Claude in multiiple herdr workspaces in parallel. When herdr gets OOM killed because claude is eating all the RAM or I simply reboot my laptop without stopping herdr first, then the first line shows claude --resume <session id>.
However I use devenv.sh for reproducible development environments and this takes a while to load.
The problem is that the claude --resume is not really executed:
claude --resume bd0035b4-9ea5-44c0-8b48-07a1XXXXXX
Willkommen zu fish, der freundlichen interaktiven Shell
Type help for instructions on how to use fish
direnv: loading ~/<project>/.envrc
direnv: using devenv
✓ Validating lock 36ms
✓ Configuring shell 67ms
└ ✓ Configuring cachix 13ms
└ ✓ Evaluating shell cached 20ms
✓ Loading tasks 6ms
└ ✓ Evaluating devenv.config.task.config cached 0ms
✓ Running tasks 106ms
└ ✓ devenv:enterShell 14ms
└ ✓ devenv:files 28ms
└ ✓ devenv:files:cleanup 63ms
└ ✓ devenv:enterTest skipped 0ms
lefthook.nix: lefthook configuration up to date
direnv: export +AR +AS +CC +CONFIG_SHELL +CXX +DETERMINISTIC_BUILD +DEVENV_CMDLINE +DEVENV_DIRENVRC_ROLLING_UPGRADE +DEVENV_DIRENVRC_VERSION +DEVENV_DOTFILE +DEVENV_PROFILE +DEVENV_ROOT +DEVENV_RUNTIME +DEVENV_STATE +DEVENV_TASKS +DEVENV_TASK_FILE +IN_NIX_SHELL +LD +LEFTHOOK_BIN +LOCALE_ARCHIVE +MANPATH +NIX_BINTOOLS +NIX_BINTOOLS_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_CC +NIX_CC_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_CFLAGS_COMPILE +NIX_ENFORCE_NO_NATIVE +NIX_HARDENING_ENABLE +NIX_LDFLAGS +NIX_PKG_CONFIG_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_PYTHONPATH +NIX_STORE +NM +OBJCOPY +OBJDUMP +PKG_CONFIG +PKG_CONFIG_PATH +PYTHONHASHSEED +PYTHONNOUSERSITE +PYTHONPATH +RANLIB +READELF +SIZE +SOURCE_DATE_EPOCH +STRINGS +STRIP +SYSTEM_CERTIFICATE_PATH +UV_PROJECT_ENVIRONMENT +UV_PYTHON_DOWNLOADS +UV_PYTHON_PREFERENCE +_PYTHON_HOST_PLATFORM +_PYTHON_SYSCONFIGDATA_NAME +cmakeFlags +configureFlags +dontAddPythonPath +hardeningDisable +mesonFlags +name +system ~NIX_SSL_CERT_FILE ~PATH ~XDG_DATA_DIRS
tobias@meliodas ~/p/c/t/dev-defaults-claude-plugins (main)>I believe that the claude --resume line needs to land at the end of the output, right?
Expected behavior
When starting herdr after a oom kill, crash or reboot, herdr waits for the terminal to be "ready" to execute the claude command, then launches it with precise timing.
Reproduction
See above. Most likely this affects just session where the shell takes a longer time to load. Interestingly it works for some of the sessions, so there might be a race condition here
Impact
Sessions do not get restored and I have to dig manually. Sometimes the printed session does not exist.
Environment
- Herdr version:0.7.3
- Update channel (stable or preview): stable
- Operating system: Ubuntu 24.04
- Terminal: Ptyxis
- Shell, if relevant: fish
- Relevant config, if any:
Is this a reproducible bug?
Current behavior
I am running Claude in multiiple herdr workspaces in parallel. When herdr gets OOM killed because claude is eating all the RAM or I simply reboot my laptop without stopping herdr first, then the first line shows
claude --resume <session id>.However I use devenv.sh for reproducible development environments and this takes a while to load.
The problem is that the
claude --resumeis not really executed:I believe that the claude --resume line needs to land at the end of the output, right?
Expected behavior
When starting herdr after a oom kill, crash or reboot, herdr waits for the terminal to be "ready" to execute the claude command, then launches it with precise timing.
Reproduction
See above. Most likely this affects just session where the shell takes a longer time to load. Interestingly it works for some of the sessions, so there might be a race condition here
Impact
Sessions do not get restored and I have to dig manually. Sometimes the printed session does not exist.
Environment