Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Surface session working directory / context on `SessionMetadata` so persisted sessions can be resumed by id

Aperta
  • Qualcosa non va?
#1,730 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
java, rust
Ambito
api, backend-api-design

Direzione di ricerca

Inizia con SessionMetadata e con i punti di ingresso list_sessions e get_session_metadata, quindi confrontali con ResumeSessionConfig, SessionListFilter e SessionRpcMetadata::snapshot. Traccia dove vengono assemblati i metadati delle sessioni inattive e come vengono rappresentati i campi di contesto esistenti. Il lavoro è completo quando entrambi gli operazioni sui metadati restituiscono campi opzionali e aggiuntivi per la directory di lavoro e il contesto e supportano la ripresa di una sessione persistita tramite il suo id.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Summary

Client::list_sessions and Client::get_session_metadata return SessionMetadata, which today carries only:

pub struct SessionMetadata {
    pub session_id: SessionId,
    pub start_time: String,
    pub modified_time: String,
    pub summary: Option<String>,
    pub is_remote: bool,
}

There is no way to recover a persisted session's working directory (or its repository / git-root / branch context) from these calls. This makes it impossible to faithfully resume a session by id after the consuming process has restarted.

Why this is a gap

ResumeSessionConfig asks the caller to supply the working directory:

pub struct ResumeSessionConfig {
    pub session_id: SessionId,
    pub working_directory: Option<PathBuf>,
    // ...
}

A consumer that persists only a session_id (the documented, stable handle for resume) and later wants to resume it has a chicken-and-egg problem: it needs the session's original working directory to resume correctly, but the SDK provides no way to look that up from the id. After a restart, the in-memory mapping from id to working directory is gone, and list_sessions / get_session_metadata don't return it.

The data already appears to exist server-side

Two public-surface signals suggest the working directory / context is already tracked per session and just isn't surfaced on SessionMetadata:

  1. SessionListFilter already lets callers filter list_sessions by cwd, git_root, repository, and branch:

    pub struct SessionListFilter {
    pub cwd: Option<String>,
    pub git_root: Option<String>,
    pub repository: Option<String>,
    pub branch: Option<String>,
}

    i.e. the server can match on these fields, but the returned metadata omits them — an asymmetry between what you can filter on and what you get back.

  2. The experimental session.metadata.snapshot RPC (SessionRpcMetadata::snapshot) already returns working_directory plus a workspace summary (cwd / git_root / repository / branch / name), selected_model, and more — but only for an active (already-resumed) session, so it can't be used to discover where a dormant session should be resumed.

Proposed change

Surface the session's working directory and context on the dormant-session metadata path, so it can be recovered by id without first resuming:

  • Add the working directory (and ideally the cwd / git_root / repository / branch context, and the user-provided name) to SessionMetadata, returned by both list_sessions and get_session_metadata.
  • All new fields optional / additive, so this is backward compatible for existing consumers.

This lets a consumer that persisted a session_id look up the session's working directory and resume it faithfully across restarts, and render accurate session lists (working directory, title) without having to resume each session first.

Alternatives considered

  • Persisting an id-to-working-directory map in the consumer. Works, but duplicates state the runtime already owns and can drift from the on-disk source of truth — hence this request to make the SDK the single source of truth.
Lingua principale
TypeScript
Stelle
10.5k
Fork
1.5k
Merge medio
1g 7h
PR unite (30g)
98

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di github/copilot-sdk

Tutte le issue di github/copilot-sdk

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.