From b24a1a022727ad53676f37ec92cf9c87f72ad17b Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 3 Aug 2026 19:53:53 +0000 Subject: [PATCH] docs: record GitHub push-permission blocker and fallback procedure Document the recurring 403 from the GitHub integration in remote sessions (git push, fork/create/create_branch/push_files all denied) and the procedure to follow: confirm with 1-2 retries, never lose work, generate a format-patch and hand it to the user via SendUserFile, report the blocker plainly instead of claiming success. --- CLAUDE.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 CLAUDE.md diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 00000000..0a4aae25 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,40 @@ +# Notas para Claude Code en este repositorio + +## Bloqueo conocido: push de GitHub en sesiones remotas (Claude Code on the web) + +En las sesiones remotas de Claude Code sobre `ares-core/mirofish`, la integración de +GitHub de esta cuenta puede no tener **ningún** permiso de escritura de referencias +sobre el repo, incluso cuando las instrucciones de la sesión piden desarrollar y +pushear a una rama designada. Esto se manifiesta como `403 Resource not accessible +by integration` en **todas** estas vías, de forma consistente y repetible: + +- `git push` directo (vía el proxy git local de la sesión) +- `mcp__github__fork_repository` +- `mcp__github__create_repository` +- `mcp__github__create_branch` +- `mcp__github__push_files` (que internamente intenta crear la rama si no existe) + +No es un problema de red transitorio ni de firma de commit (autor/email) — reintentar +el mismo comando produce el mismo 403. No hay forma de rodear esto desde la sesión: +ninguna combinación de herramientas de git/GitHub disponibles tiene permiso de +`git/refs` sobre este repo cuando ocurre. + +### Procedimiento a seguir si esto vuelve a pasar + +1. **No insistir indefinidamente.** Confirmar el bloqueo con 1-2 reintentos (incluyendo + al menos una vía distinta, p. ej. `git push` y `mcp__github__create_branch`), y si + ambas fallan igual, asumir que es el mismo bloqueo de permisos de la integración. +2. **No hacer commits/push a `main` ni a otra rama como workaround** — eso violaría + las instrucciones de alcance del repo. +3. **Nunca perder el trabajo.** Dejar todo commiteado localmente en la rama designada, + con autor `Claude ` (usar + `git config user.email noreply@anthropic.com && git config user.name Claude` antes + de commitear, para que el commit salga verificado si el hook de la sesión lo pide). +4. Generar un parche aplicable con `git format-patch -o /` y + entregarlo con `SendUserFile` para que el usuario pueda aplicarlo + (`git am 0001-*.patch`) en cuanto tenga un entorno con permisos de escritura, o + pueda revisar/ajustar los permisos de la integración de GitHub conectada a la sesión. +5. Explicar el bloqueo al usuario en términos concretos (qué herramientas fallaron, con + qué error) en vez de reportar el trabajo como "publicado" o "hecho" sin más. +6. Si el usuario confirma que corrigió los permisos, reintentar `git push` (o + `create_branch` + `push_files`) antes de volver a generar un parche.