Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Feature request: add fine grained permission control

Aberta
#299 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
typescript

Direção de pesquisa

Comece em Settings → Local execution usando o ponto de entrada grokbot://app/v1/settings?id=local-execution; a issue não nomeia arquivos de implementação nem testes. Considera-se concluído quando o switch para toda a máquina for substituído por permissões por bot e por máquina, novos bots tiverem a negação como padrão, houver prévias visíveis dos comandos e forem concedidas permissões persistentes com escopo definido.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
TypeScript
Estrelas
12.5k
Forks
1.2k
Merge médio
12h 32min
PRs com merge (30d)
115

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de cursor/plugins

Todas as issues de cursor/plugins

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.