Feature Description
When using Hermes for coding, each session is usually scoped to one repository. In practice, that repository identity is fragile in long-lived gateway/messaging sessions: after overnight compression, resume, or interruption/restart, the active conversation can lose track of which repo it belongs to and start mixing assumptions from other repos.
This is especially painful in messaging mode, where MESSAGING_CWD / TERMINAL_CWD are effectively global defaults rather than session-scoped repo bindings.
Motivation
Hermes is strong for multi-day coding sessions, but repository identity is currently carried mostly by conversational context plus whatever the current working directory happens to be. Once context is compacted, summarized, or resumed, that identity can drift.
Typical failure modes:
- a session that started in repo A later reasons as if it belongs to repo B
- compression keeps high-level task summary but drops the repo boundary
- resume/restart preserves the session but not a strong repo anchor
- terminal/file actions remain possible outside the intended repo unless the user keeps reasserting scope
For coding workflows, “which repo does this session belong to?” should be first-class session state, not just a natural-language fact that may be compressed away.
Proposed Solution
Add session-scoped repo pinning.
Possible design:
1. Session metadata
Persist structured session fields such as:
repo_root
repo_name
- optional
git_remote
- optional
default_workdir
2. User-facing command/tool
Add a way to explicitly pin the current session to a repository, for example:
/repo /path/to/repo
- or a tool/config flow that sets the session repo
3. Compression-safe repo identity
Whenever context is compacted, keep a stable repo identity block in the reconstructed context, e.g.:
- this session is pinned to
/path/to/repo
- default assumption: all coding/file/terminal work stays within this repo unless the user explicitly changes it
This repo pin should survive:
- context compression
/resume
- gateway restart / interrupted-run continuation
- previous_response_id chains
4. Tool/workdir integration
Prefer the pinned repo for:
- default terminal workdir
- context file discovery
- subdirectory hint rooting
- optional path-safety checks or warnings when a tool call escapes the pinned repo
5. Messaging/gateway support
In gateway mode, session repo pinning would be more useful than a single global MESSAGING_CWD. Different chats/threads/sessions should be able to stay attached to different repos without relying on process-global cwd.
Alternatives Considered
A. Keep using AGENTS.md + natural-language reminders
Helpful, but not sufficient. Compression can still summarize away the session’s repo identity, and global messaging cwd still creates ambiguity.
B. Only improve the compressor
Better compression helps, but it does not solve the core problem: repo identity is not modeled as durable session state.
C. Use plugins/hooks only
This may be a workable stopgap, but native session metadata would be more reliable and easier for users to understand.
Why this matters
For code sessions, a repository boundary is as fundamental as the session title or model choice. Treating repo scope as first-class session state would make Hermes much safer and more reliable for long-running coding work.
Related issues
Potentially related, but not the same problem:
This request is specifically about preserving per-session repository identity across compression/resume/restart, not just generic cwd or compression quality.
Feature Description
When using Hermes for coding, each session is usually scoped to one repository. In practice, that repository identity is fragile in long-lived gateway/messaging sessions: after overnight compression, resume, or interruption/restart, the active conversation can lose track of which repo it belongs to and start mixing assumptions from other repos.
This is especially painful in messaging mode, where
MESSAGING_CWD/TERMINAL_CWDare effectively global defaults rather than session-scoped repo bindings.Motivation
Hermes is strong for multi-day coding sessions, but repository identity is currently carried mostly by conversational context plus whatever the current working directory happens to be. Once context is compacted, summarized, or resumed, that identity can drift.
Typical failure modes:
For coding workflows, “which repo does this session belong to?” should be first-class session state, not just a natural-language fact that may be compressed away.
Proposed Solution
Add session-scoped repo pinning.
Possible design:
1. Session metadata
Persist structured session fields such as:
repo_rootrepo_namegit_remotedefault_workdir2. User-facing command/tool
Add a way to explicitly pin the current session to a repository, for example:
/repo /path/to/repo3. Compression-safe repo identity
Whenever context is compacted, keep a stable repo identity block in the reconstructed context, e.g.:
/path/to/repoThis repo pin should survive:
/resume4. Tool/workdir integration
Prefer the pinned repo for:
5. Messaging/gateway support
In gateway mode, session repo pinning would be more useful than a single global
MESSAGING_CWD. Different chats/threads/sessions should be able to stay attached to different repos without relying on process-global cwd.Alternatives Considered
A. Keep using AGENTS.md + natural-language reminders
Helpful, but not sufficient. Compression can still summarize away the session’s repo identity, and global messaging cwd still creates ambiguity.
B. Only improve the compressor
Better compression helps, but it does not solve the core problem: repo identity is not modeled as durable session state.
C. Use plugins/hooks only
This may be a workable stopgap, but native session metadata would be more reliable and easier for users to understand.
Why this matters
For code sessions, a repository boundary is as fundamental as the session title or model choice. Treating repo scope as first-class session state would make Hermes much safer and more reliable for long-running coding work.
Related issues
Potentially related, but not the same problem:
This request is specifically about preserving per-session repository identity across compression/resume/restart, not just generic cwd or compression quality.