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

Feature request: add fine grained permission control

Abierto
  • ¿Algo no está bien?
#299 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
authorization, security

Línea de trabajo

Comienza en Settings → Local execution usando el punto de entrada grokbot://app/v1/settings?id=local-execution; el issue no nombra archivos de implementación ni tests. Se considera terminado cuando el interruptor de ámbito global de la máquina se sustituya por permisos por bot y por máquina, los bots nuevos tengan la denegación como comportamiento predeterminado, se muestren vistas previas de los comandos y existan concesiones persistentes con alcance limitado.

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

Descripción

Problem

Grok Bot’s local-computer prompt is all-or-nothing across every bot on a machine.

When one bot needs to run a command on my Mac (mac.lan), the card asks (see screenshot):

Allow Grok Bot and all Bots to run commands on your local computer?

Options are Always allow, Allow once, and Never. Copy says this applies to Grok Bot and every Bot, and can be changed in Settings.

That is not the right grain. I cannot grant local execution to one bot and keep it off the others.

Why this matters

I use several Grok Bots with different duties:

  • A chief-of-staff bot (mine) that I do want to run commands on my Mac (git, gh, local clones).
  • Specialist bots I also created (slack, gitHub, product1, product2, etc.) that should not inherit that grant.

Today, “Always allow” on mac.lan is every bot I own. That breaks separation of duties. “Allow once” is too noisy for a bot I actually trust with the Mac. “Never” blocks the one bot that should have it.

I expect Grok Bots to talk to each other soon, ie my team’s bots should ask my chief-of-staff bot for permission before they act, and I decide through that bot or that bot can decide on my behalf (separate issue). That only works if permissions are per-bot. A machine-wide grant means any bot I (or later, a teammate) created can use the same local access.

Request

  1. Per-bot local execution (needed first). Let me allow/deny “run commands on this computer” per bot, per machine. Default deny for new bots. Granting xxx (or any one bot) must not grant slack, eng-abc, or any other bot I created.

  2. Visible command, scoped grant. Keep command preview on by default. Prefer grants like “this bot, this machine, this path” over a silent global allow.

  3. Bot-to-bot permission requests (next). When bots can message each other across users, let a designated bot be the policy checkpoint: other bots request, that bot (or I through it) allow/deny. Do not treat a teammate bot’s ask as an approved local-computer grant.

Settings → Local execution should show a per-bot matrix, not one switch for all bots.

Out of scope for v1

I am not asking to remove Auto-review or the allow-once prompt. I am asking that a lasting allow be bound to a specific bot (and machine), not the whole fleet.

Workaround today

I can tell the chief-of-staff bot not to hand Mac/git/gh work to other bots, and I can refuse teammate-bot asks until I approve them. That is policy in chat, not enforcement. The product still lets every bot use the Mac if I click Always allow.
Image

Lenguaje dominante
TypeScript
Estrellas
8.8k
Forks
819
Merge medio
14 h 37 min
PR fusionados (30 d)
66

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 cursor/plugins

Todos los issues de cursor/plugins

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.