Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,730 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
java, rust
Área
api, backend-api-design

Línea de trabajo

Comienza con SessionMetadata y los puntos de entrada list_sessions y get_session_metadata; después, compáralos con ResumeSessionConfig, SessionListFilter y SessionRpcMetadata::snapshot. Rastrea dónde se ensamblan los metadatos de las sesiones inactivas y cómo se representan los campos de contexto existentes. Se considera completado cuando ambos métodos de metadatos devuelven campos opcionales y aditivos de directorio de trabajo y contexto, y admiten reanudar una sesión persistida mediante su id.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
10.5k
Forks
1.5k
Merge medio
1 d 7 h
PR fusionados (30 d)
98

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/copilot-sdk

Todos los issues de github/copilot-sdk

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.