Refresh the project plugins of a remote checkout without a restart
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 63/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- developer-experience, tooling
Línea de trabajo
Start with src/node/services/agentPlugins/remoteProjectPlugins.ts and read how clearRemoteProjectPluginSnapshots is used and how remote plugin snapshots are read. Then trace the workspace-open flow and command palette or keybind registration to compare the proposed refresh options. Done means a refresh clears the relevant cached snapshot and the next read performs one listing exec, while cache hits still avoid remote execs.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
After #6426 (b2b), Xum reads the project Agent Plugins of a trusted SSH or Docker checkout once and keeps a snapshot until the project trust changes or Xum restarts. Edits to a plugin in a remote checkout show after you restart Xum or change the project's trust. No action refreshes the snapshot earlier.
Proposal
Pick one, or both:
- An explicit refresh action (command palette entry and keybind) that clears the remote plugin snapshots (
clearRemoteProjectPluginSnapshotsinsrc/node/services/agentPlugins/remoteProjectPlugins.ts). - Clear the snapshot of a workspace when the workspace opens.
Constraints
- Perf: no remote exec per turn on a cache hit. A refresh costs one listing exec (one SSH round trip) on the next read.
- A TTL needs a perf OK first.
Refs #6426.
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
- Lenguaje dominante
- TypeScript
- Estrellas
- 2.1k
- Forks
- 139
- Merge medio
- 3 h 40 min
- PR fusionados (30 d)
- 948
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de coder/xum
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
Los mantenedores suelen responder en 1 día
-
🤖 tests: lock in git status outgoing-count rename equivalence and clarify index-lock commentAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
🤖 fix: Daytona startAndWait can start a sandbox after its deadline and then report a timeoutAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
Issues similares
-
Broken links in the docsAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
liberation-data/drivine#428 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
GitLab: a merge request closed without merging keeps the Git toolbar on View MR instead of Create MRAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
code-yeongyu/oh-my-openagent#11731 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100