Cron --workdir is not reflected in the agent's system prompt Current working directory field
Summary
When a cron job is registered with --workdir <PATH>, Hermes correctly initializes the terminal tool with cwd=<PATH>, but the system prompt injected into the agent still reports Current working directory: <scheduler-cwd> (the directory from which the gateway was launched, typically ~/.hermes/hermes-agent).
The model trusts the system prompt over pwd, so its first action is often cd <wrong-dir>. The job then operates on the wrong filesystem location for the rest of the tick — silently producing no work, or worse, mutating the wrong repo.
Environment
- Hermes Agent v0.13.0 (2026.5.7), Python 3.11.13
- Linux 6.8.0-111-generic
- Model:
claude-haiku-4-5 via custom:anthropic-direct provider
- Cron registered via
hermes cron create ... --workdir /tmp/tdd-sandbox-calc
Repro
- Create a sandbox dir with
.agent/ (so it's a valid workspace for a skill that expects pwd to be the workspace):
mkdir -p /tmp/repro-cwd/.agent
cd /tmp/repro-cwd && git init -q && echo "agent/main" > .agent/branch
git add -A && git commit -qm "init"
- Register a cron with
--workdir:
hermes cron create "every 1 day" \
"Run pwd and ls -la .agent/ — report which directory you are in." \
--name repro-cwd \
--workdir /tmp/repro-cwd
- Trigger it:
JOB_ID=$(hermes cron list | grep -oE '^\s+[a-f0-9]{12}' | head -1 | tr -d ' ')
hermes cron run --accept-hooks "$JOB_ID"
- Inspect the session JSON in
~/.hermes/sessions/session_cron_<id>_*.json:
SESS=$(ls -t ~/.hermes/sessions/session_cron_*.json | head -1)
jq -r '.system_prompt | strings' "$SESS" | grep -E "Current working directory|workdir"
Expected
Current working directory: /tmp/repro-cwd
Actual
Current working directory: /home/nexus/.hermes/hermes-agent
(or wherever the gateway was started from)
Meanwhile, the terminal tool itself is correct — ~/.hermes/logs/agent.log shows:
INFO [cron_<id>_...] tools.environments.base: Session snapshot created (session=..., cwd=/tmp/repro-cwd)
So the workdir is being honored somewhere in the stack (terminal tool initialization), just not in the system prompt the model reads.
Real-world impact
We hit this with tdd-coder, a skill that drives an autonomous TDD loop in a sandboxed git repo. The skill's step 1 says export WORKSPACE="$(pwd)" because the documented contract is "Hermes places the cron in the right cwd". The model, however, reads the system prompt and prepends cd /home/nexus/.hermes/hermes-agent to its first command — so it never reaches the workspace, never invokes the preflight script, and the tick produces zero work while still consuming tokens. The bug is silent: agent returns [SILENT] and the scheduler reports success.
Workaround on our end: add a guard to step 1 that aborts the skill if pwd doesn't match a valid workspace, and explicitly tell the model in the skill NOT to trust the Current working directory field. This restores correctness for our case but doesn't help any other skill that assumes the documented contract.
Suggested fix
Wherever the system prompt template renders Current working directory:, source the value from the job's workdir (the same value used to construct the terminal tool's cwd), not from os.getcwd() of the scheduler process.
Likely locations to audit:
run_agent.py — where the cron task's system prompt is built
- The function that exposes "host context" to the system prompt template
Logs
Relevant lines from a real run (cron_6c7295c5e077 on 2026-05-13 10:47):
2026-05-13 10:47:34,866 INFO cron.scheduler: Running job 'tdd-tick-tdd-sandbox-calc' (ID: 6c7295c5e077)
2026-05-13 10:47:34,866 INFO cron.scheduler: Job '6c7295c5e077': using workdir /tmp/tdd-sandbox-calc
2026-05-13 10:47:38,550 INFO ... tools.environments.base: Session snapshot created (session=504a4ccee07a, cwd=/tmp/tdd-sandbox-calc)
2026-05-13 10:47:44,902 INFO cron.scheduler: Job '6c7295c5e077': agent returned [SILENT] — skipping delivery
First tool_call the model issued (extracted from the saved session JSON):
{"function": {"name": "terminal", "arguments": {"command": "cd /home/nexus/.hermes/hermes-agent && pwd && ls -la .agent/ 2>&1 | head -20"}}}
The cd /home/nexus/.hermes/hermes-agent was added by the model on its own initiative based on the system prompt — not requested by the user prompt.
Cron
--workdiris not reflected in the agent's system promptCurrent working directoryfieldSummary
When a cron job is registered with
--workdir <PATH>, Hermes correctly initializes the terminal tool withcwd=<PATH>, but the system prompt injected into the agent still reportsCurrent working directory: <scheduler-cwd>(the directory from which the gateway was launched, typically~/.hermes/hermes-agent).The model trusts the system prompt over
pwd, so its first action is oftencd <wrong-dir>. The job then operates on the wrong filesystem location for the rest of the tick — silently producing no work, or worse, mutating the wrong repo.Environment
claude-haiku-4-5viacustom:anthropic-directproviderhermes cron create ... --workdir /tmp/tdd-sandbox-calcRepro
.agent/(so it's a valid workspace for a skill that expectspwdto be the workspace):--workdir:~/.hermes/sessions/session_cron_<id>_*.json:Expected
Actual
(or wherever the gateway was started from)
Meanwhile, the terminal tool itself is correct —
~/.hermes/logs/agent.logshows:So the workdir is being honored somewhere in the stack (terminal tool initialization), just not in the system prompt the model reads.
Real-world impact
We hit this with
tdd-coder, a skill that drives an autonomous TDD loop in a sandboxed git repo. The skill's step 1 saysexport WORKSPACE="$(pwd)"because the documented contract is "Hermes places the cron in the right cwd". The model, however, reads the system prompt and prependscd /home/nexus/.hermes/hermes-agentto its first command — so it never reaches the workspace, never invokes the preflight script, and the tick produces zero work while still consuming tokens. The bug is silent: agent returns[SILENT]and the scheduler reports success.Workaround on our end: add a guard to step 1 that aborts the skill if
pwddoesn't match a valid workspace, and explicitly tell the model in the skill NOT to trust theCurrent working directoryfield. This restores correctness for our case but doesn't help any other skill that assumes the documented contract.Suggested fix
Wherever the system prompt template renders
Current working directory:, source the value from the job'sworkdir(the same value used to construct the terminal tool'scwd), not fromos.getcwd()of the scheduler process.Likely locations to audit:
run_agent.py— where the cron task's system prompt is builtLogs
Relevant lines from a real run (
cron_6c7295c5e077on 2026-05-13 10:47):First tool_call the model issued (extracted from the saved session JSON):
{"function": {"name": "terminal", "arguments": {"command": "cd /home/nexus/.hermes/hermes-agent && pwd && ls -la .agent/ 2>&1 | head -20"}}}The
cd /home/nexus/.hermes/hermes-agentwas added by the model on its own initiative based on the system prompt — not requested by the user prompt.