Três configurações para preservar seu ambiente de desenvolvimento existente antes de instalar o Omarchy
O Omarchy, uma distribuição opinativa baseada em Arch Linux lançada sob a liderança do Basecamp, combina o compositor de mosaico Hyprland e o kit de ferramentas de desktop Quickshell para exibir uma tela de trabalho refinada logo após a instalação padrão. É um sistema atraente para engenheiros cansados de gerenciar arquivos dotfiles manualmente, mas sobrescrever o diretório home existente diretamente fará com que até o gerenciador de sessões pare de funcionar.
Para instalar o Omarchy sem quebrar seu Neovim atual, os contêineres Docker e o ambiente de shell personalizado, você precisa primeiro isolar três pontos específicos de conflito.
Isolamento de arquivos de configuração e configuração de repositório Git bare
A maioria das falhas de inicialização durante o processo de migração de distribuição começa a partir de conflitos entre arquivos de tempo de execução antigos fora da especificação XDG e as configurações padrão do sistema. O Omarchy usa uma estrutura onde as configurações do sistema ficam em /usr/share/omarchy e as configurações de substituição do usuário são forçadas em ~/.config. Se o seu hyprland.conf anterior ou a folha de estilos do Waybar permanecerem como estão, os parâmetros entrarão em conflito com os módulos nativos do Quickshell (~/.config/omarchy/shell.json), fazendo com que a tela pare na etapa de handshake do Wayland. O terminal padrão também pode falhar ao capturar o driver gráfico devido a um PATH ou LD_LIBRARY_PATH não padrão deixado em scripts de shell.
Para preservar a forma sem mexer no ambiente existente, você deve usar o padrão de repositório Git bare (nu), que mapeia a árvore de trabalho para o diretório home. Métodos que vinculam links simbólicos um por um, como o GNU Stow, param de funcionar se houver arquivos existentes, tornando a reversão trabalhosa.
`bash
git init --bare "HOME/.dotfiles.git"aliasdotfiles=′/usr/bin/git−−git−dir=HOME/.dotfiles.git/ --work-tree=HOME′dotfilesconfig−−localstatus.showUntrackedFilesnodotfilesadd /.config/nvim /.config/tmux /.zshrc /.gitconfigdotfilescommit−m"chore:snapshotpre−omarchy"dotfilesarchive−−format=tar.gz−o"HOME/pre_omarchy_backup_$(date +%Y%m%d).tar.gz" HEAD
`
Depois de criar o arquivo de backup, mova os diretórios de desktop causadores de conflito para uma pasta isolada fora do diretório home.
`bash
mkdir -p "HOME/.configquarantine"fordirinhyprwaybarfootalacrittyrofi;do[−d"HOME/.config/dir" ] && mv "HOME/.config/dir""HOME/.config_quarantine/"
done
`
Ao remover as configurações de desktop, o Quickshell padrão do Omarchy será executado normalmente, e as configurações do editor de código e do shell do terminal poderão ser mantidas em seu estado original.
Isolamento do kernel de agentes de IA usando Bubblewrap
O Omarchy integra profundamente ferramentas de código de IA, como Claude Code ou OpenCode, no fluxo de trabalho interno do desktop. O problema é que essas ferramentas herdam as permissões do terminal host exatamente como estão. Como muitos tempos de execução restringem apenas a execução de subprocessos sem monitorar as chamadas de sistema de E/S de arquivos, a injeção de prompt ou a execução inesperada de scripts expõe vulneravelmente as pastas ~/.ssh, ~/.aws, ~/.gnupg e o socket do Docker.
Você precisa criar um ambiente de execução com privilégios mínimos usando o Bubblewrap, que lida com namespaces de usuários não privilegiados no kernel Linux. Ao sobrescrever a pasta de chaves de autenticação confidenciais com uma montagem de memória vazia, você pode bloquear a própria operação de leitura.
`bash
#!/usr/bin/env bash
/usr/local/bin/agent-jail: Executor de isolamento de agente de IA baseado em Bubblewrap
set -euo pipefail
WORKSPACE="{1:-(pwd)}"
DUMMY_DIR=(mktemp−d/tmp/jail−empty−XXXXXX)trap′rm−rf"{DUMMY_DIR}"' EXIT
exec bwrap
--ro-bind /usr /usr
--ro-bind /lib /lib
--ro-bind /lib64 /lib64
--ro-bind /bin /bin
--ro-bind /etc/resolv.conf /etc/resolv.conf
--ro-bind /etc/ssl /etc/ssl
--ro-bind /etc/ca-certificates /etc/ca-certificates
--proc /proc
--dev /dev
--tmpfs /tmp
--tmpfs "$HOME"
--bind "WORKSPACE""WORKSPACE"
--ro-bind "DUMMYDIR""HOME/.ssh"
--ro-bind "DUMMYDIR""HOME/.aws"
--ro-bind "DUMMYDIR""HOME/.gnupg"
--unshare-all
--share-net
--unshare-pid
--new-session
--die-with-parent
--setenv PATH "/usr/local/bin:/usr/bin:/bin"
--setenv HOME "$HOME"
--chdir "$WORKSPACE"
-- /usr/bin/opencode "$@"
`
Você também deve evitar colocar chaves de API em texto puro em variáveis de ambiente globais. Criar um arquivo ai.env no diretório ~/.config/secure-vault com permissões chmod 700, definir as permissões como chmod 600 e carregá-lo em um subshell apenas no momento da execução do script impede o vazamento de tokens por meio de consultas a /proc/$PID/environ.
Conversão nativa do LSP do Neovim e correção de permissões de montagem do Docker rootless
O local que mais frequentemente apresenta falhas ao migrar configurações existentes do Neovim para o Omarchy é o plugin Mason. Os binários pré-compilados que o Mason baixa do GitHub entram em conflito com os símbolos glibc mais recentes em um ambiente de lançamento contínuo (rolling release), gerando erros de execução.
Desativar o download automático de binários do Mason e redirecionar os caminhos do LSP para pacotes nativos do repositório oficial do Arch resolve esse problema. Ao remover a etapa de download de rede e a camada de wrapper, o tempo de carregamento inicial do editor também cai para menos de 30ms.
`lua
-- ~/.config/nvim/lua/plugins/lsp-native.lua
return {
{
"williamboman/mason.nvim",
opts = { auto_install = false },
},
{
"neovim/nvim-lspconfig",
opts = {
servers = {
gopls = { cmd = { "/usr/bin/gopls" } },
pyright = { cmd = { "/usr/bin/pyright-langserver", "--stdio" } },
rust_analyzer = { cmd = { "/usr/bin/rust-analyzer" } },
lua_ls = { cmd = { "/usr/bin/lua-language-server" } },
},
},
},
}
`
Após configurar, instale os binários diretamente no terminal:
`bash
sudo pacman -S --needed gopls pyright rust-analyzer lua-language-server ripgrep fd
`
O último obstáculo é o Docker. O Omarchy usa o Docker Rootless por padrão. Devido às regras de mapeamento de sub-UIDs do kernel, há um deslocamento (offset) entre a propriedade de arquivos do host e os privilégios de usuário dentro do contêiner.
Se o número inicial atribuído em /etc/subuid for 100000, um usuário comum dentro do contêiner (UID 1000) será reconhecido do ponto de vista do host como UID 100999 (100000+1000−1). É por isso que ocorre um erro bloqueando a permissão de gravação ao fazer a montagem de vínculo (bind mount) do código-fonte (-v $(pwd):/workspace). Se você definir regras de herança de Lista de Controle de Acesso (ACL) POSIX no diretório do projeto, poderá abrir permissões de gravação para o processo do contêiner sem bagunçar a propriedade do host.
`bash
#!/usr/bin/env bash
docker-rootless-align: Correção automática de permissão de montagem de volume sub-UID do Docker Rootless
set -euo pipefail
TARGET_PATH="{1:-(pwd)}"
CURRENT_USER=$(whoami)
SUBUID_START=(grep "^{CURRENT_USER}:" /etc/subuid | cut -d: -f2 || true)
if [[ -z "SUBUIDSTART"]];thensudousermod−−add−subuids100000−165535−−add−subgids100000−165535"{CURRENT_USER}"
SUBUID_START=100000
fi
HOST_MAPPED_UID=$(( SUBUID_START + 1000 - 1 ))
setfacl -R -m "u:HOSTMAPPEDUID:rwx""TARGET_PATH"
setfacl -R -d -m "u:HOSTMAPPEDUID:rwx""TARGET_PATH"
sudo loginctl enable-linger "${CURRENT_USER}"
systemctl --user enable --now docker.service
`
Depois de concluir as configurações, verifique as instâncias de janela ativas com hyprctl instances no terminal e confirme a operação do LSP com nvim --headless "+checkhealth" +qa. Quando o comando docker run --rm alpine ping -c 1 1.1.1.1 passar pela rede do subnamespace, tudo estará pronto para você continuar suas tarefas normais de desenvolvimento.