Guia prático para configurar o Zed no Linux para desenvolvimento, Markdown e IA

O objetivo deste guia é preparar a base técnica para montar depois um setup reproduzível do Zed no Fedora e no Kubuntu/Ubuntu. O foco é o uso diário com JavaScript, TypeScript, Python, Rust, Docker, bancos de dados, Markdown, Git, terminal e agentes de IA. A pesquisa não tenta transformar o Zed em uma cópia do VS Code ou do Cursor: ela separa o que o editor faz nativamente, o que depende de extensão, o que ainda exige terminal ou aplicativo externo e o que permanece experimental.

O recorte temporal foi verificado em 29 de agosto de 2026 e toma como referência o Zed 1.17.2, publicado em 26 de agosto de 2026. O editor evolui depressa; chaves de configuração, modelos de IA, adaptadores e extensões devem ser reconferidos na referência oficial de configurações e nas notas da versão estável antes de gerar o arquivo definitivo.

Resumo executivo

O Zed já pode ser o editor principal deste perfil, com algumas fronteiras claras:

• A base nativa madura inclui edição, painéis e multibuffers, terminal, Git, Markdown com preview, JavaScript/TypeScript com vtsls, Python com basedpyright e Ruff, Rust com rust-analyzer, tarefas, debugger DAP e SSH.
• Dev Containers e partes do ecossistema de IA/agents são nativos, mas ainda mudam mais depressa do que edição, LSP, terminal ou Git.
• As extensões de base são Dockerfile, SQL e Codebook; Biome, Markdownlint e Markdown Oxide só entram quando o projeto realmente precisar.
• Não há explorador de schemas, grade de dados ou console gráfico nativo para PostgreSQL, MySQL/MariaDB, SQLite e MongoDB. A extensão SQL edita arquivos, mas não substitui um cliente de banco.
• O fluxo atual de IA gira em torno do Zed Agent, Inline Assistant, Edit Prediction, External Agents via ACP e Terminal Threads. A antiga arquitetura do Assistant/Rules não deve orientar uma configuração nova.
• Um setup limpo adota o keymap do Zed, reaproveita poucos atalhos de memória muscular, instala poucas extensões e mantém as convenções no repositório.
• No Linux, o binário oficial requer Vulkan 1.3 e portais desktop. Wayland é suportado. Problemas de GPU devem ser diagnosticados antes de aplicar variáveis ou forçar XWayland.
• Novos worktrees abrem restritos. MCPs, agentes, tasks e configurações de projeto são superfícies de execução; segredos ficam no keyring, em variáveis ou em cofres, nunca em JSON versionado.

Recomendação em uma frase

Começar com o Zed quase padrão, acrescentar apenas Dockerfile, SQL e Codebook, usar as ferramentas nativas de cada linguagem, deixar regras de lint/format no próprio repositório e ativar IA gradualmente com confirmação de ferramentas e sandbox.

Metodologia e critérios

A apuração priorizou a documentação oficial do Zed, a referência completa de settings, o repositório oficial, o registro oficial de extensões e as notas de versão. Issues e discussões oficiais foram usadas apenas para confirmar ausências, limitações ou recursos ainda não incorporados.

As classificações empregadas no texto são:

Não foram transportadas chaves de dotfiles antigos. Os nomes citados abaixo aparecem na documentação ou na referência atual. Onde o guia propõe um comportamento sem fornecer JSON, a intenção é deliberada: o settings.json final deverá ser gerado e testado em uma segunda etapa.

1. Estrutura de configuração atual do Zed

O ponto de partida é separar preferências pessoais, regras compartilhadas pelo repositório e arquivos operacionais como tasks e debug. Essa divisão evita um settings.json global enorme e reduz surpresas entre projetos.

Arquivos e precedência

No Linux, a configuração global fica em ~/.config/zed/settings.json, ou em $XDG_CONFIG_HOME/zed/settings.json quando XDG_CONFIG_HOME está definido. O comando zed: open settings file abre o arquivo. A interface pesquisável Settings Editor, aberta com Ctrl+,, cobre a maior parte das opções, mas configurações avançadas de linguagens e formatters ainda podem exigir edição do JSON. A documentação confirma JSON com comentários //, isto é, JSONC na prática. Fonte oficial

Configurações do repositório ficam em .zed/settings.json. Elas sobrescrevem as globais para aquele worktree e podem tratar tabulação, formatador, LSP, associações de arquivo e outros comportamentos de projeto. Preferências de interface, como tema ou modo Vim, pertencem à configuração do usuário. Subdiretórios também podem ter settings mais específicos, mas convém evitar uma cascata difícil de entender.

A precedência conceitual é:

1. padrões internos do Zed;
2. ~/.config/zed/settings.json;
3. .zed/settings.json do projeto;
4. settings mais locais aplicáveis ao arquivo;
5. .editorconfig para propriedades que o Zed reconhece.

Em uma sessão remota há três camadas: interface local, configuração do servidor remoto e .zed/settings.json do projeto. Tema e fonte ficam locais; caminhos de LSP e proxy que só existem no servidor ficam na configuração remota; convenções do repositório ficam no projeto. Documentação de desenvolvimento remoto

Estrutura e schema

O arquivo é um objeto raiz. Ajustes globais ficam no nível superior; overrides de linguagem ficam em languages; configurações enviadas aos servidores ficam em lsp; terminal em terminal; IA em agent e provedores/context servers em suas respectivas seções. O arquivo padrão oficial começa com "$schema": "zed://schemas/settings". Esse URI interno ativa completions e validação dentro do Zed, mas não é hoje um schema HTTP público portátil para validadores externos. O próprio Settings Editor e o autocomplete do arquivo são as formas mais confiáveis de validar.

Procedimento de validação:

1. abrir o arquivo pelo comando do Zed, preservando o schema interno;
2. observar diagnósticos de JSON e sugestões de chave;
3. comparar a chave com Open Default Settings e All Settings;
4. salvar e verificar notificações;
5. quando envolver LSP, abrir dev: open language server logs ou usar o ícone de raio;
6. consultar zed: open log se o comportamento não mudar.

Mudanças e depreciações que importam

• Use languages, não exemplos antigos com language_overrides.
• A aprovação de ferramentas desde v0.224.0 é controlada por agent.tool_permissions.default; exemplos com agent.always_allow_tool_actions estão obsoletos. Tool Permissions
• A Rules Library foi removida. Regras reutilizáveis viraram Skills e instruções permanentes usam AGENTS.md e arquivos compatíveis. Instruções do Agent
• Settings antigos em assistant não devem ser copiados para um setup novo. A documentação atual organiza o Zed Agent sob agent e os modelos sob LLM Providers.
• Desde o Zed 1.17.2, file_scan_exclusions aceita o marcador "..." para preservar a lista padrão e acrescentar itens. Sem esse marcador, a lista informada substitui os defaults. Portanto, uma personalização segura começa com "..." e só depois inclui padrões como **/node_modules ou **/target. Essa mudança é recente e deve ser conferida nas notas da versão estável e na referência oficial.
• Para settings sensíveis a versão, usar a interface ou os padrões da versão instalada, não snippets de blogs antigos.

2. Keybindings

O keymap do usuário fica em ~/.config/zed/keymap.json. Pode ser aberto pelo editor de atalhos (Ctrl+K Ctrl+S) ou por zed: open keymap file. O formato é um array JSON de objetos com bindings, context opcional e use_key_equivalents opcional. As ações aparecem com autocomplete; a lista completa está em All Actions. Documentação de keybindings

Um binding simples associa uma sequência a uma ação, por exemplo "ctrl-right": "editor::SelectLargerSyntaxNode". Ações com parâmetros são arrays, e contextos como Editor, Terminal ou ProjectPanel && not_editing limitam onde o atalho age. Não é prudente copiar ações antigas sem confirmar o nome no Keymap Editor.

Conflitos

Bindings em contexto mais específico vencem os genéricos. No mesmo nível, o último binding carregado vence; por isso o arquivo do usuário sobrescreve o padrão. Se uma sequência for prefixo de outra, o Zed espera cerca de um segundo pelo segundo acorde. O comando dev: open key context view ajuda a descobrir por que um atalho foi interceptado.

No terminal integrado, combinações como Ctrl+N podem ser capturadas pelo workspace. O mecanismo oficial é criar um binding no contexto Terminal que chama terminal::SendKeystroke. Faça isso somente para combinações realmente necessárias, pois encaminhar tudo quebra atalhos úteis do editor.

Estratégia para quem vem de VS Code ou Cursor

A série 1.14 mudou o base_keymap padrão de VSCode para Zed; VS Code e Cursor continuam disponíveis como mapas de compatibilidade. Essa mudança aparece nas notas de versão estáveis, que prevalecem sobre páginas de referência ainda não atualizadas. Para este perfil, que quer aproveitar o modo de trabalhar do Zed, a recomendação é manter Zed e acrescentar somente os atalhos de memória muscular que resolverem uma fricção concreta. O editor já compartilha várias convenções familiares, como Ctrl+P para arquivos e Ctrl+Shift+P para comandos, mas o atalho exato deve ser conferido no Keymap Editor da versão instalada.

Atalhos nativos que vale aprender em vez de substituir:

Customizações razoáveis depois do período de adaptação: um atalho para preview Markdown ao lado, um para rerun da última task e, se necessário, forwarding específico para Ctrl+R/Ctrl+N no terminal. Evitaria reconstruir todas as teclas do Cursor.

3. Markdown e edição de texto

Markdown é nativo. O Zed usa Tree-sitter para estrutura e realce, inclusive dentro de blocos cercados de todas as linguagens conhecidas pelo editor. A documentação oficial registra Language Server: N/A no núcleo. Markdown no Zed

O que funciona sem extensão

• syntax highlighting, outline, folding estrutural e completions básicas;
• preview renderizado nativamente, sem WebView;
• markdown: open preview e markdown: open preview to the side;
• splits e panes independentes;
• links clicáveis e imagens no preview, com as limitações do renderer;
• soft wrap por largura do editor ou comprimento preferido;
• Prettier como formatador de Markdown, se desejado;
• realce da linguagem em blocos cercados;
• multibuffers, pesquisa global e múltiplos cursores para editar documentação em massa.

O preview tem opções próprias de largura e fontes. Para uma aparência editorial, limitar a largura renderizada e usar uma fonte de leitura no preview é mais útil que instalar um tema pesado.

O que não é nativo ou ainda é limitado

• Não há corretor ortográfico nativo abrangente equivalente ao VS Code + LanguageTool. A extensão Codebook Spell Checker fornece um LSP de ortografia consciente de código.
• Não existe formatador visual de tabelas no núcleo. Prettier pode normalizar tabelas, e Markdownlint diagnostica estilo, mas nenhum deles vira um editor WYSIWYG.
• Não há Markdown LSP nativo. Markdown Oxide adiciona um LSP orientado a PKM/links, enquanto Markdownlint oferece diagnósticos de lint. Instalar ambos sem necessidade pode duplicar avisos.
• O preview não pretende ser um navegador completo e pode divergir do GitHub Flavored Markdown em HTML embutido, links internos ou casos de layout. A discussão oficial mantém um rastreador de melhorias.
• Extensões de Zed não têm uma API geral de WebView, então uma extensão de Markdown não pode simplesmente replicar toda a UI do VS Code.

Recomendação

Usar Markdown nativo com preview lateral, soft_wrap por largura do editor, Prettier somente nos repositórios que já o adotam e Codebook para ortografia. Adicionar Markdownlint em documentação publicada com regras de CI. Usar Markdown Oxide apenas para um vault ou wiki com backlinks; para README e documentação técnica comum ele é excesso.

4. Node.js, JavaScript e TypeScript

JavaScript, TypeScript, TSX e JSX têm suporte nativo. O servidor padrão atual é vtsls, com typescript-language-server como alternativa. O adaptador de debugger é vscode-js-debug. Zed precisa de Node disponível; caminhos customizados ficam nas opções node.path e node.npm_path, mas o ideal é que o shell e o projeto forneçam a versão correta.

LSP, lint e formatação

• vtsls: navegação, completions, refactors, imports e diagnóstico de TypeScript. Mantenha-o como padrão salvo incompatibilidade comprovada.
• Prettier: já é o formatador padrão de TypeScript segundo a documentação atual. Em JavaScript, format-on-save vem desligado por padrão e deve ser ativado conscientemente.
• ESLint: integrado como language server/code actions. Pode executar source.fixAll.eslint durante a formatação. O Zed avisa que um formatador posterior pode desfazer o fix se ESLint e Prettier discordarem. JavaScript no Zed
• Biome: extensão comunitária mantida pelo projeto Biome, com LSP para JS, TS, JSX, TSX, JSON/JSONC, Vue, Astro, Svelte e CSS. Requer biome.json na raiz por padrão. Biome no Zed
• Organize imports: usar a code action do LSP escolhido. Não combinar vtsls, ESLint e Biome todos reorganizando imports no mesmo save.

Configuração recomendada hoje

Escolher uma das duas famílias por repositório:

1. Stack conservadora: vtsls + ESLint para lint/fixes + Prettier para formato. As regras vivem em eslint.config.* e .prettierrc/package.json, não em settings globais.
2. Stack Biome: vtsls para inteligência de TypeScript + Biome para lint, imports e formato. Não manter ESLint e Prettier ativos sem uma razão de migração.

Ativar format_on_save por projeto depois de confirmar que o resultado é igual ao CI. Em monorepos, preferir executáveis locais do workspace e abrir a raiz que contém os arquivos de configuração. Não substituir vtsls por outro servidor só por familiaridade com VS Code.

5. Python

Python é nativo. Desde Zed v0.204.0, basedpyright é o LSP principal; Ruff é usado para lint e formatação. Pyright, PyLSP e o experimental ty também são disponibilizados, mas ficam desabilitados por padrão. O debugger usa debugpy. Guia oficial de Python

Ambientes e toolchains

O Zed descobre ambientes Python por seu sistema de toolchains. Um seletor permite escolher ou informar manualmente o interpretador. O ambiente selecionado é passado aos LSPs nativos, às tasks Python e ao debugger; se for um virtualenv, novos terminais podem ativá-lo automaticamente. O terminal busca por padrão .env, env, .venv e venv, controlado por terminal.detect_venv.

• uv sync normalmente cria .venv, que o Zed encontra.
• python -m venv .venv funciona diretamente.
• Poetry é suportado pelo fato de criar/gerenciar um interpretador; se o ambiente ficar fora do projeto e não for selecionado automaticamente, use o seletor de toolchain.
• Dependências continuam sendo responsabilidade de uv, Poetry, pip ou Conda, não do editor.
• LSPs fornecidos por extensões não recebem toda a configuração automática de toolchain que os servidores nativos recebem.

Basedpyright, Ruff e Black

Basedpyright fornece tipagem, navegação, referências e inlay hints. O Zed escolhe modo standard por padrão; pyrightconfig.json ou [tool.basedpyright]/[tool.pyright] em pyproject.toml deve guardar a política do projeto. pyrightconfig.json vence pyproject.toml se ambos existirem.

Ruff roda como LSP (ruff server). A pipeline de formato tem duas fases: code_actions_on_format, como organizar imports, e o formatter. Ruff pode cuidar das duas. Se o projeto exige Black, mantenha Ruff para lint/imports e use Black como formatter externo. Desligue explicitamente o organize-imports do Ruff se não quiser que ele altere código.

Recomendação: basedpyright + Ruff, .venv local criada por uv, regras em pyproject.toml e format-on-save por projeto. Black só entra onde já for padrão. Não ativar ao mesmo tempo basedpyright, Pyright, PyLSP e ty.

6. Rust

Rust é nativo, com Tree-sitter, rust-analyzer e debugger CodeLLDB; GDB é alternativa nas plataformas compatíveis. rustfmt chega pelo LSP e o cargo/rustup do sistema. Rust no Zed

O rust-analyzer oferece inlay hints, code actions, navegação, completions e runnables. Zed também expõe tasks vindas da extensão LSP do rust-analyzer e fornece tarefas contextualizadas para testes e comandos Cargo.

Check, Clippy e desempenho

Por padrão, o rust-analyzer tem checkOnSave ativo e pode disparar cargo check --workspace --all-targets a cada save. Isso é confortável em crates pequenos, mas caro em workspaces grandes. A própria documentação recomenda limitar o check ou desligá-lo e usar a task pronta, com links clicáveis no terminal.

Clippy pode ser selecionado como comando de check do rust-analyzer ou executado por task (cargo clippy --workspace --all-targets). A escolha deve ficar em .zed/settings.json somente quando o time concordar; CI e Cargo.toml continuam sendo a fonte de verdade. Use cargo fmt --check e Clippy nas tasks de verificação, não uma sequência duplicada a cada save.

Recomendação: rust-analyzer padrão, rustfmt no save, inlay hints moderados, cargo check no save apenas em projetos pequenos e tasks explícitas para cargo test, cargo clippy e build. Excluir target/ do painel/scan somente após preservar toda a lista padrão de exclusões.

7. Docker

Docker não é nativo. A extensão atual Dockerfile informa suporte a Dockerfile e Docker Compose, com gramáticas, language servers e debug adapters. A documentação de linguagem ainda descreve Dockerfile e Compose como extensões comunitárias e identifica dockerfile-language-server e compose-language-service. Docker no Zed

A extensão antiga separada Docker Compose está sem atualização desde 2024 e só declara syntax highlighting. Para um setup novo, usar a extensão Dockerfile atual e só instalar a antiga se um tipo de arquivo concreto não for reconhecido.

O editor não é um Docker Desktop. Operações de container, logs, exec, build e Compose ficam no terminal e em tasks. Isso é coerente com o perfil: docker compose up -d, docker compose logs -f, docker compose down e validação de Compose são comandos reproduzíveis.

8. Bancos de dados

Em 29 de agosto de 2026, o Zed não possui viewer/query console nativo para PostgreSQL, MySQL/MariaDB, SQLite ou MongoDB. Não há painel de conexões, navegador de schema, grade de resultados nem editor visual de dados. A discussão oficial sobre viewer de SQLite/PostgreSQL/MySQL continua fora do produto, e pedidos de integração de banco dependem de infraestrutura de UI que a API de extensões ainda não oferece. Discussão oficial

A extensão SQL fornece linguagem e gramática. A documentação mostra formatação externa com sql-formatter e dialetos como PostgreSQL, MySQL, MariaDB e SQLite. Isso melhora arquivos .sql, mas não abre conexões. SQL no Zed

Um MCP de PostgreSQL dá contexto e ferramentas ao agente, não transforma o Zed em cliente de banco. Por segurança, MCPs de banco devem começar read-only e apontar para dados de desenvolvimento.

9. Terminal integrado

O terminal é nativo. No Unix, usa por padrão o shell de /etc/passwd. Bash, zsh e fish funcionam se configurados como shell do usuário ou informados em terminal.shell. Argumentos, como --login, usam a forma with_arguments. Terminal do Zed

Novos terminais começam por padrão no projeto do arquivo atual (current_project_directory). Também existem current_file_directory, first_project_directory, always_home e diretório fixo. O terminal aceita env, fonte, tamanho, line height, cursor, contraste e detecção de virtualenv.

Não há necessidade de criar perfis extensos como no VS Code. Para alternar ambientes, abrir terminais com shells explícitos ou usar tasks é mais transparente. O ambiente do projeto é obtido por login shell quando o projeto não foi aberto pela CLI; abrir com zed . ajuda a herdar um PATH previsível. Variáveis de ambiente

Recomendação Linux:

• deixar shell: system se o shell de login já está correto;
• manter working_directory: current_project_directory;
• não colocar secrets no bloco env versionado;
• usar line height standard para TUIs com box drawing;
• encaminhar apenas teclas que realmente conflitam;
• abrir um center terminal para TUIs longas, como lazygit ou clientes de banco, se isso melhorar o layout.

10. Git e forjas

Git é nativo e hoje cobre muito mais que o antigo status básico: Git Panel, diff por arquivo e projeto, stage/unstage por arquivo ou hunk, commit, push/pull/fetch, branches, worktrees, conflitos, stash, blame, histórico de arquivo e Git Graph. Alterações feitas no terminal aparecem no painel. Git no Zed

O editor resolve remotes conforme pushRemote, pushDefault e tracking branch do próprio Git. Para operações não cobertas, o terminal continua sendo a extensão natural. Commit signing, rebase interativo complexo, filtros avançados, manutenção de submodules e administração de remotes são exemplos em que o CLI permanece melhor.

Hashes, issues, pull requests e merge requests tornam-se links. A versão atual suporta provedores hospedados e configurações self-hosted para GitHub, GitLab, Bitbucket, Gitea, Forgejo e SourceHut. Isso não equivale a uma UI completa de PR/issue para cada forja; é integração de navegação. Forgejo/Gitea continuam funcionando normalmente como remotes Git, e tarefas/terminal cobrem os comandos específicos.

Para este perfil: usar o painel nativo para revisão, stage e commits cotidianos; Git Graph e file history para inspeção; terminal para git rebase -i, hooks, assinatura, gh, tea, forgejo ou scripts. Evitar instalar uma extensão de Git apenas para replicar o que o núcleo já oferece.

11. IA e Agent

O Zed atual separa como o agente roda de como o modelo é fornecido. Há três caminhos de agente: Zed Agent, External Agents via ACP e Terminal Threads para CLIs/TUIs. Visão geral

Recursos atuais

• Zed Agent lê, pesquisa e edita o projeto, executa terminal, usa diagnostics, Skills, instruções e MCP; mostra mudanças na revisão do Zed.
• Agent Panel e Threads Sidebar organizam conversas, contexto e trabalho paralelo.
• Inline Assistant transforma a seleção ou linha mediante prompt; aceita @ de arquivo, diretório, símbolo, thread e imagem. O atalho documentado é Ctrl+Enter no contexto aplicável. Inline Assistant
• Edit Prediction oferece sugestões automáticas enquanto se digita; é diferente do Inline Assistant, que é explícito.
• External Agents como Claude, Codex, OpenCode, Copilot, Cursor e Pi podem rodar dentro do painel via ACP, mantendo autenticação e configuração próprias.
• Terminal Threads organizam agentes CLI sem fingir que sua configuração pertence ao Zed.
• Geração de mensagem de commit, resumo de threads e outros recursos usam os provedores configurados no Zed.

Agent versus Assistant

O antigo Assistant Panel não é uma alternativa paralela moderna. A nomenclatura atual conserva Inline Assistant para edição pontual, mas o fluxo conversacional com ferramentas é o Zed Agent. Tutoriais com assistant.default_model, Rules Library ou conversas antigas em ~/.config/zed/conversations representam gerações anteriores e não devem guiar a nova configuração.

Provedores, BYOK e modelos locais

Para recursos nativos do Zed, os caminhos atuais incluem modelos hospedados pelo Zed, API própria, assinaturas compatíveis, gateways e modelos locais. A API própria suporta de primeira classe Anthropic, OpenAI, Google AI, Mistral, DeepSeek, xAI, OpenCode e endpoints compatíveis com Anthropic/OpenAI. LLM Providers

Chaves salvas pela interface ficam no keyring do sistema, não no settings.json. Variáveis como OPENAI_API_KEY e ANTHROPIC_API_KEY também são lidas e vencem o keyring quando não vazias. Em projetos SSH/dev container, o provedor de IA do Zed roda localmente e lê o keyring/ambiente da máquina local. Acesso por API

Ollama e LM Studio são suportados, assim como llama.cpp e servidores OpenAI-compatible locais. O Zed descobre modelos puxados no Ollama e modelos expostos pelo servidor do LM Studio. Modelos locais menores podem funcionar bem no Inline Assistant, mas uso agentic exige bom tool calling e contexto suficiente; rodar localmente não garante privacidade se o MCP ou o terminal ainda envia dados a terceiros. Modelos locais

Contexto, custo e privacidade

O Agent pode receber arquivos, diretórios, símbolos, diffs, diagnostics, instruções e URLs. Contexto demais aumenta custo e reduz precisão; prefira referências explícitas. Modelos hospedados pelo Zed são medidos conforme o plano e a tabela vigente. BYOK é faturado pelo provedor. Local consome CPU/GPU e memória próprias.

Segundo a política oficial, o Zed não retém prompts ou código por padrão; em modelos hospedados, existem compromissos de não treinamento e retenção zero, salvo modelos sujeitos a retenção de segurança do provedor. BYOK, assinaturas, gateways e agentes externos obedecem aos termos de seus próprios operadores. Privacidade de IA

Recomendação: começar com perfil Ask para leitura, um perfil Write com confirmação e sandbox para edição, e Inline Assistant para mudanças pequenas. Não habilitar autoaprovação global.

12. MCP

MCP é nativo para o Zed Agent e pode ser encaminhado a External Agents via ACP; Terminal Threads usam a configuração nativa do CLI. Zed suporta atualmente Tools e Prompts, além de recarregar ferramentas após notifications/tools/list_changed. Discovery, Sampling, Elicitation e outras partes do protocolo ainda não têm cobertura completa. MCP no Zed

Servidores podem ser instalados como extensões ou configurados como locais/remotos em Settings → AI → MCP Servers. O JSON gerado usa context_servers: servidores locais têm command, args e env; remotos têm url e, se necessário, headers. Sem header Authorization, o Zed pode iniciar OAuth padrão do MCP.

Exemplo estrutural oficial, com valores deliberadamente genéricos:

{
  "context_servers": {
    "local-mcp-server": {
      "command": "some-command",
      "args": ["arg-1", "arg-2"],
      "env": {}
    },
    "remote-mcp-server": {
      "url": "https://example.com/mcp",
      "headers": { "Authorization": "Bearer <token>" }
    }
  }
}

O indicador em AI Settings mostra se o servidor está ativo. Em v0.224.0 ou superior, a política padrão de ferramentas é confirm; regras específicas usam nomes como mcp:<servidor>:<ferramenta>.

Segurança de MCP

Um MCP local é um processo com os privilégios do usuário. Um MCP remoto recebe dados e pode executar ações no serviço conectado. Antes de instalar:

1. revisar repositório, mantenedor, versão e comandos;
2. limitar tokens e escopos;
3. começar read-only;
4. manter confirmação por ferramenta destrutiva;
5. não colocar token literal em .zed/settings.json versionado;
6. separar produção de desenvolvimento;
7. lembrar que MCP de banco é ferramenta do agente, não uma UI de banco.

Para o primeiro setup, eu não instalaria MCP algum. Adicionaria GitHub/Forgejo, documentação ou PostgreSQL apenas quando uma tarefa repetida justificar a nova superfície de ataque.

13. Tasks

Tasks são nativas e executam comandos no terminal integrado. O arquivo global é ~/.config/zed/tasks.json; o arquivo por worktree é .zed/tasks.json. Os comandos zed: open tasks e zed: open project tasks abrem os arquivos correspondentes. Tasks também podem vir de extensões de linguagem ou ser criadas como one-shot. Documentação oficial

Cada arquivo é um array. Campos confirmados incluem label, command, args, env, cwd, use_new_terminal, allow_concurrent_runs, reveal, hide, shell, show_summary, show_command, save, tags e hooks. Variáveis como $ZED_FILE, $ZED_RELATIVE_FILE, $ZED_DIRNAME, $ZED_WORKTREE_ROOT, $ZED_SYMBOL e $ZED_SELECTED_TEXT conectam o comando ao contexto do editor. Use args em vez de interpolação no shell para caminhos que possam conter espaços.

Modelo conceitual para este stack

O bloco abaixo usa somente campos documentados. Ele é um ponto de partida, não deve ser copiado para todos os repositórios: mantenha apenas os comandos que existem no projeto.

[
  {
    "label": "pnpm: test",
    "command": "pnpm",
    "args": ["test"],
    "cwd": "$ZED_WORKTREE_ROOT",
    "use_new_terminal": false,
    "reveal": "always",
    "save": "all"
  },
  {
    "label": "pnpm: lint",
    "command": "pnpm",
    "args": ["lint"],
    "cwd": "$ZED_WORKTREE_ROOT",
    "hide": "on_success",
    "save": "all"
  },
  {
    "label": "pytest: arquivo atual",
    "command": "python",
    "args": ["-m", "pytest", "$ZED_RELATIVE_FILE"],
    "cwd": "$ZED_WORKTREE_ROOT",
    "save": "current"
  },
  {
    "label": "cargo: test workspace",
    "command": "cargo",
    "args": ["test", "--workspace"],
    "cwd": "$ZED_WORKTREE_ROOT",
    "save": "all"
  },
  {
    "label": "cargo: clippy",
    "command": "cargo",
    "args": ["clippy", "--workspace", "--all-targets"],
    "cwd": "$ZED_WORKTREE_ROOT",
    "hide": "on_success",
    "save": "all"
  },
  {
    "label": "compose: validar",
    "command": "docker",
    "args": ["compose", "config", "--quiet"],
    "cwd": "$ZED_WORKTREE_ROOT",
    "hide": "on_success",
    "save": "all"
  },
  {
    "label": "compose: subir",
    "command": "docker",
    "args": ["compose", "up", "-d"],
    "cwd": "$ZED_WORKTREE_ROOT",
    "save": "all"
  },
  {
    "label": "compose: logs",
    "command": "docker",
    "args": ["compose", "logs", "-f", "--tail", "200"],
    "cwd": "$ZED_WORKTREE_ROOT",
    "use_new_terminal": true,
    "allow_concurrent_runs": false,
    "save": "none"
  }
]

Para npm, troque pnpm por npm e os argumentos conforme os scripts. Para Python gerenciado por uv, uma task pode chamar uv com run pytest; se o toolchain Python do Zed estiver corretamente selecionado, python -m pytest tende a ser mais universal. Tasks de build e test devem chamar scripts do repositório em vez de repetir toda a lógica do CI.

Hooks automáticos merecem cautela. O hook documentado create_worktree é útil para preparar novos worktrees, mas o exemplo oficial de copiar .env ilustra uma operação que pode vazar secrets se for adotada sem revisão. Prefira gerar .env a partir de um cofre ou copiar manualmente.

14. Debugger

O debugger é nativo e usa o Debug Adapter Protocol. Há adaptadores atuais para C, C++, Go, JavaScript, PHP, Python, Rust e TypeScript no núcleo, além de Java, Ruby, Swift e outras linguagens via extensão. Ele suporta breakpoints, stepping, variáveis, call stack, console e exception breakpoints conforme o adapter. Debugger do Zed

O caminho rápido é debugger: start (F4 duas vezes no keymap padrão documentado), que mostra cenários contextuais. Zed pode criar cenários automaticamente para Rust, Go, Python, JavaScript e TypeScript. Configurações explícitas do projeto ficam em .zed/debug.json; globais ficam ao lado do settings do usuário. Se não houver .zed/debug.json, configurações de .vscode/launch.json também podem aparecer.

Cada configuração exige adapter e label; request, program e cwd dependem do adapter. O campo build pode chamar uma task antes da sessão. Não há uma tradução universal de launch.json: o adapter é a fonte de verdade.

Limitações práticas:

• a experiência varia por linguagem e adapter;
• attach e descoberta automática não têm a mesma cobertura para todos os runtimes;
• C/C++ e algumas extensões exigem debug.json manual;
• depuração dentro de container/SSH depende de o adapter e o programa existirem no ambiente remoto;
• recursos muito específicos do VS Code podem não ser importados.

Para este perfil, usar auto scenarios primeiro e criar .zed/debug.json apenas para serviços Node, scripts Python ou binários Rust que precisam de variáveis/argumentos fixos.

15. Extensions

A galeria abre com Ctrl+Shift+X ou zed: extensions. Cada extensão pode ser instalada, removida e inspecionada ali. No Linux, os arquivos ficam em $XDG_DATA_HOME/zed/extensions ou ~/.local/share/zed/extensions, divididos em installed e work. Atualizações ocorrem automaticamente na inicialização, salvo extensões fixadas com auto_update_extensions. Instalação de extensões

auto_install_extensions permite tornar o conjunto reproduzível. O valor true instala e false impede instalação automática. Isso é preferível a versionar a pasta binária de extensões.

Tabela de extensões recomendadas

Extensões rodam em Wasm e têm capabilities, mas ainda podem baixar/lançar LSPs e ferramentas. A capability system permite restringir execução, downloads e instalação de pacotes; revisar permissões faz parte da instalação.

16. Temas e aparência

Temas e icon themes podem vir do núcleo ou de extensão. O seletor de tema usa Ctrl+K Ctrl+T; o icon theme é escolhido por action. Fontes de buffer, UI e terminal são independentes. O Zed suporta fallbacks e recursos OpenType; ligatures podem ser desligadas com a feature calt. Aparência

Aparência limpa e editorial

• Manter um tema claro/escuro sóbrio e um único pacote de ícones.
• Usar uma fonte monoespaçada legível no buffer e terminal; uma fonte de UI sem serifa é opcional.
• Manter line height confortável para Markdown e standard no terminal se TUIs desenharem bordas.
• Deixar minimap desligado, que já é o padrão atual, porque File Finder, outline e scrollbar cumprem melhor o papel.
• Manter breadcrumbs e status bar, pois dão contexto de símbolo, branch, linguagem e diagnostics com pouco custo visual.
• Usar tabs com preview e fechamento no hover em vez de dezenas de tabs fixas.
• Preservar Project Panel com git status e diagnostics, fechando-o por atalho quando quiser foco.
• Limitar a largura do preview Markdown e escolher fonte de leitura separada se necessário.

Transparência, blur, UI extremamente compacta e dezenas de overrides de cor são frágeis entre versões e não melhoram o trabalho. Antes de editar JSON, testar a interface do Settings Editor.

17. Performance e Linux

O Zed é rápido por arquitetura, mas LSPs, watchers, check-on-save, extensões e agentes podem dominar o consumo. Em projetos grandes, convém medir antes de otimizar.

Scanning e diretórios grandes

O Zed respeita .gitignore em muitos fluxos. file_scan_exclusions remove arquivos do scan, da pesquisa e do painel. No Zed 1.17.2, use "..." como primeiro item para conservar os padrões oficiais e depois acrescentar exclusões próprias. Sem "...", a lista personalizada substitui os defaults. Em vez de esconder sempre node_modules e target, prefira .gitignore; só exclua completamente se a busca e navegação nesses diretórios nunca forem úteis.

Pontos de maior impacto:

• rust-analyzer com check de workspace/all-targets a cada save;
• monorepos JS com múltiplos LSPs e linters sobre o mesmo arquivo;
• diretórios acima de 100 mil arquivos, especialmente remotos;
• file_scan_inclusions amplo;
• seguir symlinks sem necessidade;
• Agent/MCPs e terminais mantendo processos pesados;
• previews e logs contínuos em vários panes.

Vulkan, Wayland e GPUs híbridas

O build oficial Linux requer CPU x86_64/aarch64, glibc compatível e Vulkan 1.3, além de portais FileChooser, OpenURI e Secret. Fedora e Ubuntu atuais atendem normalmente. Instalação

O Zed suporta Wayland e X11. A documentação recomenda vkcube e vkcube -m wayland|x11 para testar Vulkan; zed --system-specs e ~/.local/share/zed/logs/Zed.log mostram GPU/driver. Em falha de surface, XWayland pode ser testado com WAYLAND_DISPLAY="", mas isso é diagnóstico, não configuração permanente recomendada. Zed no Linux

Em notebooks híbridos, o log mostra qual GPU foi escolhida. DRI_PRIME=1 pode forçar a discreta em alguns sistemas; /etc/prime-discrete aparece na documentação para certos setups. Usar essas opções apenas se a integrada falhar ou o desempenho for ruim. Zed é um editor, portanto forçar NVIDIA discreta pode gastar bateria sem ganho perceptível. KDE Plasma e GNOME são suportados pelos mesmos caminhos Wayland/X11; problemas tendem a ser de driver ou portal, não de uma edição específica do Zed para KDE.

No Fedora, o pacote Terra e o Flatpak são comunitários; no Ubuntu/Kubuntu, o script oficial é o caminho mais direto. Pacotes comunitários podem estar atrasados ou renomear o binário. Para consistência entre as duas distros, o instalador oficial facilita comparar bugs com a versão estável.

18. Remote development

SSH remoto é nativo. A UI e os modelos do Zed ficam locais; arquivos, LSPs, tasks e terminais rodam no servidor por meio de um Zed headless server enviado/baixado após a conexão SSH. O recurso exige Zed v0.159 ou superior, portanto está amplamente presente na versão atual. Remote Development

Pode-se abrir o diálogo Remote Projects ou usar URLs como zed ssh://usuario@host/caminho. A configuração SSH existente, keys e opções suportadas são reaproveitadas. Extensões locais são propagadas ao servidor. Não abrir / ou $HOME inteiro em hosts com centenas de milhares de arquivos; escolher o diretório do projeto.

Limitação oficial atual: não se pode abrir um arquivo do terminal remoto digitando zed arquivo. Alguns fluxos e extensions do VS Code Remote SSH não têm equivalente, e o ecossistema de extensões do Zed é menor. Em contrapartida, Zed usa SSH direto; a UI permanece local e simples.

Dev Containers são suportados, mas a documentação marca o recurso como em desenvolvimento. O editor lê .devcontainer/devcontainer.json, pode abrir o projeto no container e executa terminal/tasks/LSPs lá. Alterar devcontainer.json não reconstrói/recarrega automaticamente: é preciso matar/reiniciar e reabrir. Extensões podem ser indicadas em customizations.zed.extensions. Dev Containers

WSL é relevante principalmente no Windows; para Fedora/Kubuntu nativos, SSH e Dev Containers são os caminhos corretos. Comparado ao VS Code Remote SSH, o Zed já cobre edição, LSP, terminal, tasks, Git, debugger e IA, mas tem menos integração com features proprietárias e um ciclo de dev container ainda menos polido.

19. Project settings

.zed/settings.json deve conter apenas decisões compartilháveis do repositório:

• formatter e format-on-save por linguagem;
• LSP selecionado e parâmetros necessários ao projeto;
• associações de arquivo;
• tabulação, largura e wrap quando forem convenções do time;
• exclusões específicas, preservando os defaults;
• configuração de test/debug quando a equipe aceita o formato.

.zed/tasks.json guarda comandos reproduzíveis e .zed/debug.json cenários de debugger. Configurações das ferramentas devem continuar nos padrões do ecossistema: biome.json, eslint.config.*, pyproject.toml, ruff.toml, pyrightconfig.json, rustfmt.toml, Cargo.toml, compose.yaml e afins. Assim o CI e outros editores compartilham a mesma regra.

Não colocar tema, fonte, atalhos pessoais, keys, tokens, caminhos absolutos do computador ou MCPs com credenciais na pasta .zed. Ao clonar projetos de terceiros, Restricted Mode impede inicialmente que settings, LSPs e MCPs do worktree sejam aplicados até a confiança explícita.

20. Segurança

O modelo de ameaça inclui mais do que IA. Language servers e extensões baixam binários; project settings podem disparar servidores; tasks executam shell; terminais têm privilégios do usuário; MCPs ligam serviços externos; agentes podem editar e executar comandos.

Controles atuais

• Worktree Trust faz novos diretórios começarem em Restricted Mode. Até confiar, .zed/settings.json, LSPs e MCPs do projeto não rodam. A confiança vale por host em SSH/WSL. Worktree Trust
• Tool Permissions oferecem regras allow/deny/confirm por ferramenta e padrão; mantenha confirm para terminal e MCPs mutáveis.
• Agent Profiles separam Ask, que pode ser read-only, Write, que habilita edição/terminal, e Minimal, sem ferramentas de projeto.
• No Linux, o sandbox do terminal/fetch do Zed Agent usa bubblewrap (bwrap) quando disponível. Ele protege writes, .git e rede, mas não se aplica a tasks, terminal normal, LSPs, extensions, External Agents ou Terminal Threads. Sandboxing
• Chaves de provedores salvas pela UI ficam no keyring do sistema.
• Extension capabilities podem limitar execução, download e instalação.

Recomendações

1. Instalar bubblewrap e manter sandbox ativo.
2. Nunca ativar session.trust_all_worktrees de forma permanente.
3. Revisar .zed/, .vscode/, AGENTS.md, tasks e scripts ao clonar código desconhecido.
4. Não versionar .env, tokens, headers Authorization ou chaves de API.
5. Dar tokens MCP com menor escopo possível e sem produção por padrão.
6. Não permitir que agentes executem sudo, acessem Docker socket ou SSH sem confirmação específica.
7. Verificar diffs e tests antes de aceitar mudanças do agente.
8. Tratar acesso ao Docker daemon como privilégio equivalente a root em muitos setups.

21. Backup e sincronização

O Zed não exige versionar diretórios de cache/data. Para recriar o ambiente, guardar em um repositório privado de dotfiles:

• ~/.config/zed/settings.json, sem segredos;
• ~/.config/zed/keymap.json;
• ~/.config/zed/tasks.json, se houver tasks globais;
• ~/.config/zed/snippets/*.json;
• ~/.config/zed/AGENTS.md, apenas se não contiver informação privada;
• uma lista declarativa em auto_install_extensions no settings;
• instruções de instalação de fontes e CLI tools.

Não versionar ~/.local/share/zed/extensions, language servers baixados, logs, workspace DB ou keys do keyring. O mapa auto_install_extensions permite reinstalar extensões na outra máquina; por padrão elas se atualizam automaticamente. Isso reproduz o conjunto, não garante byte a byte a mesma versão. Fixar versões pela UI/auto_update_extensions só quando uma regressão justificar.

Por projeto, versionar .zed/settings.json, .zed/tasks.json e .zed/debug.json se a equipe usa Zed e revisou o conteúdo. O restore em nova máquina é: instalar Zed, restaurar configs, instalar fontes/ferramentas, abrir o projeto, revisar Restricted Mode e selecionar toolchains.

22. Snippets

Snippets são nativos. A pasta Linux é ~/.config/zed/snippets, aberta por snippets: open folder. O comando snippets: configure snippets cria/abre um arquivo por escopo. Somente formato JSON é suportado. Snippets

O nome de arquivo é o nome da linguagem em minúsculas, como python.json, rust.json e typescript.json. snippets.json é global; JSX usa javascript.json; Plain Text usa plaintext.json. Cada snippet tem nome e body; prefix e description são opcionais. Placeholders usam $1, ${1:valor} e $0.

Exemplo oficial adaptado somente no texto:

{
  "Log to console": {
    "prefix": "log",
    "body": ["console.info(\"${1:value}\");", "$0"],
    "description": "Insere console.info"
  }
}

Limitações documentadas: se prefix for uma lista, somente o primeiro é usado; só JSON é aceito. Para um setup limpo, criar snippets apenas para padrões pessoais realmente frequentes. LSPs e completions já cobrem boilerplate comum.

23. Recursos úteis não citados

Além dos recursos pedidos no briefing, os componentes abaixo têm impacto direto no fluxo diário e merecem entrar no setup.

Multibuffers

Busca, referências e diagnostics podem ser reunidos em um único buffer editável. Isso permite mudar vários arquivos com múltiplos cursores sem abrir dezenas de tabs. É uma das diferenças mais úteis do jeito Zed. Multibuffers

Project Diagnostics e inline diagnostics

Diagnostics vêm dos LSPs, podem ser vistos por projeto e opcionalmente como error lens inline. Ativar lens para tudo pode poluir a tela; usar o painel e ligar inline somente quando estiver corrigindo uma leva de erros. Diagnostics

Toolchains

O seletor de toolchain não é só Python: ele representa ferramentas da linguagem por projeto. É preferível a caminhos absolutos globais e ajuda em ambientes remotos. Toolchains

Git worktrees e agentes paralelos

O Zed cria/navega worktrees e pode isolar threads paralelas em checkouts distintos. Isso é útil para IA, mas não deve ser ativado antes de dominar Git worktree e os custos de múltiplos processos. Parallel Agents

REPL/Jupyter

O REPL nativo usa kernels Jupyter para Python e outras linguagens, e pode executar seleções/células inline. É útil para exploração de dados ou scripts, mas não é necessário no setup core de backend. REPL

CLI

zed ., caminhos com linha/coluna, --diff, --foreground, --system-specs e completions de shell integram o editor ao terminal. Para este perfil, instalar completions e usar zed . deve fazer parte do setup. CLI

Tabela de LSP, formatter e linter por linguagem

Diferenças importantes para quem vem do Cursor/VS Code

1. As extensões têm escopo menor. Não há equivalência um-para-um com a Marketplace; extensões do Zed oferecem linguagens, LSPs, temas, snippets, MCP, agentes e debug adapters, mas não podem montar qualquer painel/WebView.
2. Multibuffer é central. Busca, referências, diagnostics e project diff viram superfícies editáveis. Vale aprender isso em vez de reproduzir abas e sidebars do VS Code.
3. O terminal faz parte do desenho. O Zed não tenta embutir um cliente gráfico para cada banco ou serviço. Tasks transformam comandos recorrentes em ações sem esconder sua natureza.
4. A configuração é menor e mais direta. Há Settings Editor, JSON global e .zed/ por projeto; não existe a mesma massa de settings contribuídos por extensões VS Code.
5. A IA é modular. Zed Agent, External Agent e Terminal Thread são caminhos distintos; provider não é sinônimo de agent. Um login ChatGPT/Cursor também não é automaticamente uma chave OpenAI para o Zed Agent.
6. Keymap compatível não significa comportamento idêntico. Splits, seleção sintática, panes e terminal têm contextos próprios. Conservar algumas ações nativas reduz conflitos.
7. O desenvolvimento remoto é mais simples, mas menos abrangente. SSH e dev containers já executam backend remoto, porém a superfície de extensions e integração do VS Code Remote continua maior.
8. O Git nativo é suficiente para o cotidiano. Antes de procurar GitLens, usar blame, file history, Git Graph, project diff, worktrees e stash existentes.
9. O preview Markdown usa renderer próprio. É rápido e nativo, mas não é um Chromium e pode divergir de extensões complexas do VS Code.
10. A importação é parcial. O importador oficial traz várias preferências, mas não extensões nem keybindings personalizados. Migração do VS Code

Configurações que parecem boas, mas eu não usaria

Setup conceitual recomendado

O setup abaixo organiza as escolhas anteriores em camadas. Ele é conceitual de propósito: cada camada deve ser validada antes que a seguinte seja adicionada.

Core

• Instalação oficial estável nas duas distros.
• Keymap Zed nativo, autosave conservador e settings mínimo; atalhos de VS Code/Cursor apenas quando houver necessidade comprovada.
• File Finder, command palette, outline e multibuffers como navegação principal.
• Defaults de scan preservados; .gitignore como primeira linha contra artefatos.

Coding

• JS/TS: vtsls e, por repositório, ESLint + Prettier ou Biome.
• Python: basedpyright + Ruff, .venv criada por uv, toolchain selecionado.
• Rust: rust-analyzer + rustfmt, check-on-save adaptado ao tamanho.
• Regras em arquivos da ferramenta, não escondidas no editor.

Markdown

• Suporte/preview nativos, preview ao lado e wrap por largura.
• Codebook para ortografia.
• Markdownlint somente em projetos com regras; Markdown Oxide apenas para PKM.

Git

• Painel, project diff, Git Graph, blame, history, stash e worktrees nativos.
• CLI para rebase avançado, assinatura e administração de remotes.
• Configurar links self-hosted para Forgejo/Gitea apenas quando necessário.

Terminal

• Shell do sistema, diretório do projeto e PATH vindo do login shell.
• Center terminal para TUIs; forwarding apenas de conflitos concretos.
• Secrets fora de terminal.env versionado.

AI

• Zed Agent com perfis Ask/Write e confirmação de terminal/MCP.
• Sandbox via bubblewrap.
• Um provider primeiro: BYOK, hosted ou local conforme custo/privacidade.
• Inline Assistant para mudanças pequenas; External Agent/Terminal Thread só se houver fluxo real.

Extensions

• Base: Dockerfile, SQL e Codebook.
• Biome, TOML e frameworks sob demanda.
• Um tema e um icon theme no máximo.
• Declarar o conjunto em auto_install_extensions depois de validar os IDs.

Tasks

• test, lint, build, cargo test/clippy, pytest e operações Compose específicas do repo.
• Chamar scripts existentes; evitar duplicar CI.
• Tasks globais só para ferramentas universais.

Appearance

• Tema sóbrio, fonte legível, minimap desligado, tabs de preview.
• Project Panel e status bar presentes, fechados por atalho quando necessário.
• Preview Markdown com largura limitada.

Linux

• Wayland nativo, Vulkan 1.3 e portais corretos.
• vkcube, log e --system-specs como diagnóstico.
• GPU integrada por padrão; PRIME/XWayland somente como workaround comprovado.
• Comparar comportamento usando o mesmo canal stable nas duas distros.

Lista dos arquivos que precisaremos criar depois

Não é necessário criar todos. O setup final deve começar pelos quatro arquivos globais principais e acrescentar .zed/ somente em repositórios que se beneficiam disso.

Recomendações práticas

A implantação progressiva é mais segura do que copiar uma configuração completa de uma vez, especialmente quando formatters, agentes e MCPs podem modificar arquivos ou executar comandos.

Implantação em cinco fases

1. Semana 1: instalar stable oficial, usar o keymap Zed, terminal, Git, Markdown e linguagens nativas sem IA ou extensões além de Dockerfile/SQL.
2. Semana 2: escolher toolchains, ligar format-on-save somente em repos de teste, adicionar Codebook e criar tasks de test/lint.
3. Semana 3: ativar Zed Agent em perfil Ask, configurar um provider e bubblewrap, testar Inline Assistant com arquivos não sensíveis.
4. Semana 4: criar perfil Write com confirmação, revisar diffs, adicionar somente o MCP que resolver um problema real.
5. Depois: consolidar settings/keymap/snippets em dotfiles e testar restauração em uma VM ou segunda máquina.

Checklist antes do settings definitivo

• Confirmar Zed 1.17.2 ou versão mais recente instalada.
• Abrir Default Settings e copiar somente chaves atuais.
• Decidir por ESLint + Prettier ou Biome em cada projeto.
• Confirmar dicionários PT-BR/EN do Codebook no upstream.
• Medir rust-analyzer em workspace real antes de alterar check-on-save.
• Verificar Dockerfile atual com os nomes de Compose usados pelo usuário.
• Testar Vulkan/Wayland em Fedora e Kubuntu.
• Definir se IA será hosted, BYOK ou local.
• Instalar bwrap e manter worktree trust.
• Validar todos os arquivos no Zed e rodar os tasks em repositório descartável.

Conclusão

O Zed já tem base suficiente para este conjunto de trabalho no Linux. A melhor configuração não é a mais longa: é aquela que conserva o núcleo rápido, delega lint e formato aos arquivos do projeto, usa o terminal para serviços que não pertencem ao editor e adiciona extensões e MCPs apenas quando existe uma lacuna concreta.

As principais concessões frente ao Cursor/VS Code são a ausência de um ecossistema de extensões com UI arbitrária e de um cliente gráfico de banco. Em troca, o Zed oferece edição estrutural, multibuffers, Git e remote integrados, tasks diretas e uma arquitetura de IA que distingue agentes, providers e ferramentas. Para o próximo passo, o settings definitivo deve ser pequeno, testado na versão instalada e dividido entre preferências pessoais e convenções de cada repositório.

Links oficiais de referência

• Índice completo da documentação do Zed
• Versões estáveis do Zed
• Repositório oficial zed-industries/zed
• Referência de todas as configurações
• Arquivo de settings padrão no repositório
• Keybindings
• Todas as actions
• Configuração de linguagens
• Markdown
• JavaScript
• TypeScript
• Biome
• Python
• Rust
• Docker
• SQL
• Terminal
• Tasks
• Debugger
• Git
• Remote Development
• Dev Containers
• Instalação no Linux
• Solução de problemas no Linux
• Extensões
• Registro oficial de extensões
• Snippets
• Aparência
• Migração do VS Code
• Visão geral de IA
• Zed Agent
• Inline Assistant
• LLM Providers
• Acesso por API e armazenamento de chaves
• Modelos locais, Ollama e LM Studio
• MCP
• Tool Permissions
• Agent Sandboxing
• Privacidade de IA
• Worktree Trust
• Instruções e AGENTS.md
• Repositório oficial de extensões
• Discussão oficial sobre integração de banco

Nota sobre atualidade

Pesquisa concluída em 29 de agosto de 2026. O Zed mantém ciclo rápido de releases, e os pontos mais sujeitos a mudança são modelos/provedores de IA, permissions, debugger, Dev Containers, Git providers e extensões. Antes de criar o settings.json definitivo, confirmar as chaves na versão instalada e nas fontes oficiais acima.