fix(kanban): forward session context vars into worker subprocess env

[wernerhp]

What does this PR do?

Kanban workers spawned by _default_spawn inherit os.environ but not the gateway's ContextVar session state (HERMES_SESSION_PLATFORM, HERMES_SESSION_CHAT_ID, HERMES_SESSION_THREAD_ID). Workers therefore have no originating thread context -- send_message calls land as new root posts instead of replying in the correct thread.

Fix: add build_session_subprocess_env() to gateway/session_context.py and use it in _default_spawn to overlay ContextVar values onto the worker's env before Popen. The existing except ImportError guard keeps the standalone CLI and test environments working unchanged.

Workers now inherit the originating platform/chat/thread, enabling send_message to auto-target the correct thread without requiring the thread_id to be baked into the kanban task brief.

Related Issue

Relates to #45940 (same root cause, complementary fix -- that PR adds build_session_subprocess_env() + explicit --subscribe-* CLI flags; this PR wires the helper into _default_spawn). Also related to #56781 (addresses the notification delivery side of the same dispatch gap).

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Changes Made

• gateway/session_context.py: add build_session_subprocess_env(base_env) -- builds a subprocess env dict with ContextVar session values overlaid on top of os.environ (or a provided base).
• hermes_cli/kanban_db.py: _default_spawn calls build_session_subprocess_env(dict(os.environ)) instead of dict(os.environ) directly; falls back to dict(os.environ) on ImportError for CLI/test safety.

How to Test

1. Start the gateway on a Mattermost/Telegram session.
2. Create a kanban task assigned to a profile that calls send_message in its worker.
3. Before: worker posts to channel root (no thread context).
4. After: worker posts as a thread reply in the originating conversation thread.

Checklist

• Commit messages follow Conventional Commits
• Searched existing PRs -- complements fix: auto-subscribe on CLI kanban create + check SendResult in notifier #45940/fix(kanban): deliver auto-subscriptions from dispatcher-spawned workers #56781, does not conflict
• PR contains only changes related to this fix
• Tested on: Ubuntu 24.04, Python 3.11

[Copilot]

Pull request overview

This PR fixes kanban worker subprocesses spawned by hermes_cli.kanban_db._default_spawn not inheriting the gateway session ContextVar state (e.g., HERMES_SESSION_PLATFORM, HERMES_SESSION_CHAT_ID, HERMES_SESSION_THREAD_ID), which previously caused worker send_message calls to lose thread targeting and post as new root messages.

Changes:

• Add build_session_subprocess_env() in gateway/session_context.py to overlay session ContextVar values into a subprocess environment.
• Update hermes_cli/kanban_db.py::_default_spawn to use build_session_subprocess_env(dict(os.environ)) when available, with a fallback for non-gateway contexts.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
gateway/session_context.py	Introduces a helper to construct subprocess envs that include session ContextVar state.
hermes_cli/kanban_db.py	Uses the helper during kanban worker spawn to preserve originating platform/chat/thread context.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[teknium1]

Thanks for tracing the ContextVar/subprocess boundary. Current main still has the raw-environment gap at hermes_cli/kanban_db.py:8085, so the underlying issue is real.

Problems

• The stated send_message outcome is not reached by this change. tools/send_message_tool.py:354-369 obtains chat_id and thread_id only from target; when absent, tools/send_message_tool.py:442-461 selects a configured home channel. Neither path reads HERMES_SESSION_CHAT_ID or HERMES_SESSION_THREAD_ID, so forwarding those variables alone cannot make a direct send reply in the originating thread.
• The new helper iterates all of _VAR_MAP, but gateway/session_context.py:123-139 includes session key/ID/profile and cron auto-delivery variables beyond the requested platform/chat/thread routing context. That broadens the worker's inherited session identity without a demonstrated consumer.

Suggested changes

• Wire and test the actual origin-target resolution path for worker delivery, preserving explicit targets.
• Limit the Kanban bridge to the ContextVars required by that path, or add coverage explaining each additional identity/delivery variable.

This is an automated hermes-sweeper review.

[wernerhp]

Both review findings are addressed:

• send_message origin outcome — fixed in 6adc7041d. A worker send_message with no explicit target now resolves to the forwarded session origin (HERMES_SESSION_PLATFORM/CHAT_ID/THREAD_ID) so the reply lands back in the originating thread; an explicit target is parsed earlier and still wins, never overridden. Tests cover origin-fallback, explicit-target-priority, and rejection when neither is present.
• over-broad ContextVar forwarding — fixed in 6adc7041d, hardened in 98388fd8f. build_session_subprocess_env now forwards only the narrow routing set (platform, chat_id, thread_id) instead of all HERMES_SESSION_* vars; the narrowed set is asserted in the tests.

[wernerhp]

Closing as superseded by main.

The underlying concern (a detached kanban worker inheriting a previous gateway turn's send_message routing) is now handled on main in the opposite direction. Rather than forwarding the originating session's routing ContextVars into the worker subprocess, the dispatcher strips them:

# hermes_cli/kanban_db.py, worker spawn env
from gateway.session_context import _VAR_MAP
for key in _VAR_MAP:
    env.pop(key, None)

This PR's build_session_subprocess_env does the reverse (inherit rather than isolate), which would reintroduce the cross-session leak main now guards against. The two are mutually exclusive, so rebasing forward is not the right move.

If per-task routing forwarding is still wanted, an explicit opt-in on the task, layered on top of the default isolation, would be the safer shape than a blanket inherit at spawn.