Could we have an auto dispatcher kill switch? I made changes in config and set dispatch_in_gateway: false and restart. That didn't work. So I thought dispatch_interval_seconds was the problem so I set it 0. That didn't work. So I found it was still processing in the background even tho I restarted a couple times. It even crashed my mac-mini a couple times. The cause was I had a bunch of triage stories and somehow the hermes update that restarted the gateway which cause the dispatcher auto compose the triage stories (big ones) created over a hundred tasks and assigned them to many different profiles which exhausted all my tokens because it happened over night. I keep going in a loop of putting all the tasks to todo but it keeps putting them back into progress while also exhausting my mac-mini and keep restarting it. I also put the tasks in triage one by one and somehow it keep putting them progress. Now I had to run free models and bought more credits to help troubleshooted this issue. Everything auto is off now. And i have the headache of going in to triage each tasks one by one. It'll be quite lovely to have a kill switch or some sort and a default rule to never ever ever auto decompose triage stories. Thanks for attending my ted talk!
#Kanban Auto Dispatcher
indigo prawn
I set this up after the fact:
- ~/.hermes/config.yaml — added triage_lock: true to the kanban: section
- kanban-orchestrator skill — added triage_lock enforcement: if true, no worker will dispatch, claim, or complete a triage task — it stays quarantined until you manually move it via SQL or board UI
What this means:
• Triage tasks are now sticky — auto-dispatcher (and any kanban-orchestrator worker) will refuse to touch them
• You control when a triage task moves to todo/ready/claimed — all manual
• The 54 tasks currently in triage will stay there
shell horizon
The setting you wanted first is kanban.auto_decompose: false.
kanban.dispatch_in_gateway: false disables the embedded gateway dispatcher on startup, but it is broader than triage decomposition and only applies to the gateway/profile that actually read that config. dispatch_interval_seconds: 0 will not disable it; current code treats 0 as “use the default” and falls back to 60 seconds.
For the immediate stop, shut the gateway down first:
hermes gateway stop
Then set both of these in the active profile config:
hermes config set kanban.auto_decompose false
hermes config set kanban.dispatch_in_gateway false
Then start the gateway again only after confirming you are editing the same profile/home that the gateway is using:
hermes gateway list
hermes gateway start
If you want the env-level emergency brake too, add this to the active ~/.hermes/.env and restart the gateway:
HERMES_KANBAN_DISPATCH_IN_GATEWAY=0
One important note: triage_lock is not a core Hermes config key right now, so adding it to config.yaml will not stop the built-in dispatcher unless your own local skill/code is reading it.
Please send a fresh hermes debug share after the gateway is stopped/restarted with those settings if it still moves tasks. The main thing to verify is whether another profile/gateway or a forced standalone kanban daemon is still running against the same board.
indigo prawn
ok good to know! HERMES_KANBAN_DISPATCH_IN_GATEWAY is good to know