Hashline edits no Oh My OpenAgent: o que é, como funciona e quando vale ligar

Fala aí, beleza? Tem um recurso de edição ancorada em hash dentro do Oh My OpenAgent que está desligado na tua máquina agora mesmo, e provavelmente tu nem sabia que ele existe

O projeto é um harness/plugin de agente de código mantido no GitHub por code-yeongyu (YeonGyu-Kim), no repositório oh-my-openagent

Ele é distribuído em três edições do mesmo produto: dois plugins que carregam dentro de um host que tu já roda (OpenCode e Codex CLI) e uma edição standalone

E o hashline edits é opt-in, ou seja: vem desabilitado por padrão e só liga se você pedir

Esse post aqui é curto e específico, pra quem JÁ usa o produto e quer fuçar o que vem desligado de fábrica =)

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Como funciona o formato LINE#ID por baixo do capô

A ideia é simples de entender: em vez de o agente apontar "linha 42", ele aponta pra uma referência no formato LINE#ID

LINE é o número da linha (base 1, começando em 1 mesmo)

ID é um hash derivado do conteúdo normalizado daquela linha

E aí? Cada linha que o agente lê volta marcada com esse hash de conteúdo

Na hora de editar, o hash é conferido contra o estado atual do arquivo. Se o conteúdo mudou desde o Read, o hash não bate e a edição é rejeitada antes de corromper o arquivo

Se você conhece checksum de download, é a mesma vibe: o número sozinho não prova nada, o hash prova que é aquilo mesmo que você leu

Junto com o recurso vem um hook companheiro, o hashline-read-enhancer, ativado automaticamente quando você liga a chave. A função dele é anotar a saída do Read com os marcadores LINE#ID, que é o que alimenta a edit tool depois

O que muda na edição de código quando você liga

Quando ligado, o hashline edits substitui a ferramenta Edit built-in por uma versão hash-anchored

Na prática, dois incômodos clássicos da edição por agente saem de cena

O primeiro: some a necessidade de reproduzir espaçamento exato. Aquele drama de o agente precisar acertar o whitespace na unha pra casar o trecho antigo, tchau

O segundo: caem os erros de stale-line, porque a edição é validada contra o estado atual do arquivo, e não contra a foto que o agente tirou três minutos atrás

O objetivo declarado do recurso é justamente esse: evitar alucinação de linha

Se o agente inventar um número de linha, a edição é REJEITADA em vez de aplicada. E olha que diferença absurda isso faz: falhar alto é muito melhor do que escrever no lugar errado e você descobrir dois commits depois

Só que vamos ser honestos aqui: isso é uma troca de comportamento da tool Edit, não mágica. Não é um modelo mais esperto, é uma validação a mais no caminho

Quando vale ligar o hashline edits (e quando não faz diferença)

Os cenários onde o mecanismo brilha saem direto do que ele faz

• Arquivo que muda entre o Read e o Edit: você editando o mesmo arquivo junto com o agente, formatter ou linter rodando no salvamento, outro processo tocando o arquivo. É exatamente o caso que a validação por hash pega
• Arquivos grandes, onde a chance de o agente errar a linha cresce e o erro passa despercebido
• Código com indentação sensível (Python, YAML e afins), onde não precisar reproduzir whitespace exato tira um pé da armadilha

Agora o contraponto honesto

Se suas sessões são curtas, em arquivo pequeno e sem edição concorrente, o ganho tende a ser pequeno. Não tem drama nenhum em continuar com a Edit padrão

E isso ajuda a explicar por que quase ninguém liga: recurso que vem desligado só é ligado por quem sente a dor que ele resolve

É a mesma lógica de manter só o que você realmente usa quando o assunto é enxugar custo de VPS desligando recursos: default ligado pra todo mundo cobra um preço de quem não precisa

Como habilitar o hashline edits no omo.jsonc

A configuração unificada do harness mora no arquivo omo.jsonc, e o passo a passo é bem curtinho

1. Abra a configuração certa. A camada de usuário fica em ~/.omo/omo.jsonc (menor precedência) e a camada de projeto em .omo/omo.jsonc, com o arquivo mais próximo vencendo

2. Adicione a chave hashline_edit com valor true. No JSON schema ela é um booleano, então é isso e mais nada

{
  // troca a Edit built-in pela edit tool ancorada em hash
  "hashline_edit": true
}

Nota de formato: os arquivos aceitam JSONC, com comentários e trailing commas permitidos, então esse // aí em cima não vai quebrar nada

3. Opcional: desligue só o hook companheiro. Se por algum motivo você quiser a edit tool ancorada em hash sem o hashline-read-enhancer anotando a saída do Read, a chave disabled_hooks desliga o hook companheiro sem desligar o resto

O erro comum desse passo a passo? Editar arquivo legado

Os arquivos legados oh-my-openagent.json e oh-my-openagent.jsonc, junto com oh-my-opencode.json e oh-my-opencode.jsonc, não são mais lidos em runtime: eles são importados uma vez pelo motor de migração e só. Se você mexeu ali e "não aconteceu nada", provavelmente é isso. Tome cuidado!

Instalação: qual edição você precisa ter antes

Se você caiu aqui sem ter o produto instalado, se liga na parte chata primeiro

O recurso aparece listado na Ultimate Edition (o omo para OpenCode), na condição de opt-in

# Ultimate Edition (OpenCode)
bunx oh-my-openagent install

# Light Edition (Codex CLI)
npx lazycodex-ai install

# edição standalone, canal beta
npm i -g omo-ai@beta

Dois avisos que a documentação faz questão de dar

O primeiro: não use bunx omo nem npx omo. Aqui a confusão é de NOME DE PACOTE: no npm, omo é um pacote diferente, de outro autor, sem relação nenhuma com esse projeto, e é pra ele que esses comandos resolvem

E atenção pra não misturar as coisas: uma coisa é o pacote omo do npm (de terceiro), outra é o bin omo, o comando. Esse bin foi removido dos pacotes oh-my-openagent/oh-my-opencode nesse major, e hoje o comando vem da edição standalone, que se instala pelo pacote omo-ai em canal beta

O segundo aviso: instalação global não é oficialmente suportada pros plugins (nada de npm install -g, bun add -g ou bun install -g), porque é plugin e ele precisa resolver de onde o OpenCode/Codex carrega plugins. Rode cada edição pelo runner do bloco acima (bunx na Ultimate, npx na Light) em vez de instalar global

Vale a pena ligar? O próximo passo

Meu veredito aqui é bem direto: é um opt-in de baixo custo pra experimentar

A chave é um booleano, então ligar é uma linha e voltar atrás é apagar essa linha. Não tem migração, não tem cerimônia, não tem caminho sem volta

O próximo passo concreto: coloque hashline_edit: true na camada de projeto (.omo/omo.jsonc) de UM repositório só, de preferência aquele com arquivo grande e formatter agressivo

Rode uma sessão de edição real e compare com o que você já conhece do comportamento padrão

Se ajudar, promove pra camada de usuário. Se atrapalhar, remove a chave e segue a vida

É recurso desligado por padrão, então o autor também não está prometendo bala de prata: quem decide é o teu fluxo de trabalho

Até o próximo post! 🙂