Skip to content

Feature: session-scoped repo pinning to preserve repository identity across compression/resume #10309

@hansonyu183

Description

@hansonyu183

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Low — cosmetic, nice to havecomp/agentCore agent loop, run_agent.py, prompt buildercomp/gatewayGateway runner, session dispatch, deliverytype/featureNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions