“cli_ar” — Fediverse search results on home.social

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

#ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd

#archlinux #bootfailure #debugging #devops #dhcp #dropbear

Kevin @[email protected] · 2026-05-12 · 21:56 UTC

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

#ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd

#archlinux #bootfailure #debugging #devops #dhcp #dropbear

Kevin @[email protected] · 2026-05-12 · 21:56 UTC

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

#ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd

#archlinux #bootfailure #debugging #devops #dhcp #dropbear

Kevin @[email protected] · 2026-05-12 · 21:56 UTC

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

#ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd

#systemdnetworkd #sysadmin #serveroutage #pythoncli #postmortem #pacman

Kevin @[email protected] · 2026-05-12 · 21:56 UTC

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

#ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd

#archlinux #bootfailure #debugging #devops #dhcp #dropbear

Jan @[email protected] · 2024-12-28 · 19:55 UTC

Updated https://fittrackee.escuco.de/ to #fittrackee v.0.8.7

- new sport #swimrun
- bug fix CLI - fix limit for user data export cleanup
- some translation updates

Many thanks to @FitTrackee and all contributors.

The way I see it, a lot of work is currently being put into FitTrackee. The first v0.9 beta pre-releases are here and it seems to be heading towards federation. I think it's going to be a blast.

#opensource #selfhosting #running #cycling #biking #laufen #radfahren #activitytracker

#fittrackee #swimrun #opensource #selfhosting #running #cycling

Jan @[email protected] · 2024-12-28 · 19:55 UTC

Updated https://fittrackee.escuco.de/ to #fittrackee v.0.8.7

- new sport #swimrun
- bug fix CLI - fix limit for user data export cleanup
- some translation updates

Many thanks to @FitTrackee and all contributors.

The way I see it, a lot of work is currently being put into FitTrackee. The first v0.9 beta pre-releases are here and it seems to be heading towards federation. I think it's going to be a blast.

#opensource #selfhosting #running #cycling #biking #laufen #radfahren #activitytracker

#fittrackee #swimrun #opensource #selfhosting #running #cycling

Jan @[email protected] · 2024-12-28 · 19:55 UTC

Updated https://fittrackee.escuco.de/ to #fittrackee v.0.8.7

- new sport #swimrun
- bug fix CLI - fix limit for user data export cleanup
- some translation updates

Many thanks to @FitTrackee and all contributors.

The way I see it, a lot of work is currently being put into FitTrackee. The first v0.9 beta pre-releases are here and it seems to be heading towards federation. I think it's going to be a blast.

#opensource #selfhosting #running #cycling #biking #laufen #radfahren #activitytracker

#activitytracker #radfahren #laufen #biking #cycling #running

Jan @[email protected] · 2024-12-28 · 19:55 UTC

Updated https://fittrackee.escuco.de/ to #fittrackee v.0.8.7

- new sport #swimrun
- bug fix CLI - fix limit for user data export cleanup
- some translation updates

Many thanks to @FitTrackee and all contributors.

The way I see it, a lot of work is currently being put into FitTrackee. The first v0.9 beta pre-releases are here and it seems to be heading towards federation. I think it's going to be a blast.

#opensource #selfhosting #running #cycling #biking #laufen #radfahren #activitytracker

#fittrackee #swimrun #opensource #selfhosting #running #cycling

Habr @[email protected] · 2026-05-14 · 12:42 UTC

Claude ест токены впустую, но я его прокачал

В материале расскажу вам о инструменте для AI-ассистента работающего CLI на PHP + SQLite. Который парсит проект, строит графы зависимостей и даёт Claude точечный доступ к коду: конкретный метод, поля класса, цепочка наследования, все SQL-запросы к таблице — одной командой, без чтения файлов целиком. Сейчас поддерживает Go , PHP и JavaScript, позже добавлю и C.ссылочка на гитхаб внизу) Claude знает структуру проекта — но недостаточно хорошо Claude Code читает CLAUDE.md , понимает архитектуру, знает какие файлы за что отвечают. Но когда доходит до дела — всё равно читает файлы целиком. Нужен один метод — читает весь класс. Нужно найти где вызывается функция — читает директорию за директорией. Контекст тает, а реальной работы ещё не было. К тому моменту как он добрался до ответа, контекст уже наполовину занят файлами которые я и сам мог открыть.Или другой сценарий: нужно понять какие поля у сущности. Claude читает файл целиком, хотя там нужны только первые 20 строк с полями и конструктором.Контекстное окно — главный ресурс при работе с AI на большом проекте. Тратить его на чтение файлов целиком расточительно.Меня это раздражало. Написал инструмент. Что я сделал Написал два PHP-скрипта: buildGraph.php — сканирует проект и строит граф зависимостей в SQLite. Парсит PHP и JS: классы, методы, вызовы, импорты, наследование. Запуск инкрементальный — повторный проход обновляет только изменённые файлы за 100–200 мс. claudeSearch.php — CLI-интерфейс. Даёт AI точечный доступ к коду одной командой.

https://habr.com/ru/articles/1035206/

#ai #claude_code #deepseek

#deepseek #claude_code #ai

Habr @[email protected] · 2026-05-14 · 12:42 UTC

Claude ест токены впустую, но я его прокачал

В материале расскажу вам о инструменте для AI-ассистента работающего CLI на PHP + SQLite. Который парсит проект, строит графы зависимостей и даёт Claude точечный доступ к коду: конкретный метод, поля класса, цепочка наследования, все SQL-запросы к таблице — одной командой, без чтения файлов целиком. Сейчас поддерживает Go , PHP и JavaScript, позже добавлю и C.ссылочка на гитхаб внизу) Claude знает структуру проекта — но недостаточно хорошо Claude Code читает CLAUDE.md , понимает архитектуру, знает какие файлы за что отвечают. Но когда доходит до дела — всё равно читает файлы целиком. Нужен один метод — читает весь класс. Нужно найти где вызывается функция — читает директорию за директорией. Контекст тает, а реальной работы ещё не было. К тому моменту как он добрался до ответа, контекст уже наполовину занят файлами которые я и сам мог открыть.Или другой сценарий: нужно понять какие поля у сущности. Claude читает файл целиком, хотя там нужны только первые 20 строк с полями и конструктором.Контекстное окно — главный ресурс при работе с AI на большом проекте. Тратить его на чтение файлов целиком расточительно.Меня это раздражало. Написал инструмент. Что я сделал Написал два PHP-скрипта: buildGraph.php — сканирует проект и строит граф зависимостей в SQLite. Парсит PHP и JS: классы, методы, вызовы, импорты, наследование. Запуск инкрементальный — повторный проход обновляет только изменённые файлы за 100–200 мс. claudeSearch.php — CLI-интерфейс. Даёт AI точечный доступ к коду одной командой.

https://habr.com/ru/articles/1035206/

#ai #claude_code #deepseek

#deepseek #claude_code #ai

Habr @[email protected] · 2026-05-14 · 12:42 UTC

Claude ест токены впустую, но я его прокачал

В материале расскажу вам о инструменте для AI-ассистента работающего CLI на PHP + SQLite. Который парсит проект, строит графы зависимостей и даёт Claude точечный доступ к коду: конкретный метод, поля класса, цепочка наследования, все SQL-запросы к таблице — одной командой, без чтения файлов целиком. Сейчас поддерживает Go , PHP и JavaScript, позже добавлю и C.ссылочка на гитхаб внизу) Claude знает структуру проекта — но недостаточно хорошо Claude Code читает CLAUDE.md , понимает архитектуру, знает какие файлы за что отвечают. Но когда доходит до дела — всё равно читает файлы целиком. Нужен один метод — читает весь класс. Нужно найти где вызывается функция — читает директорию за директорией. Контекст тает, а реальной работы ещё не было. К тому моменту как он добрался до ответа, контекст уже наполовину занят файлами которые я и сам мог открыть.Или другой сценарий: нужно понять какие поля у сущности. Claude читает файл целиком, хотя там нужны только первые 20 строк с полями и конструктором.Контекстное окно — главный ресурс при работе с AI на большом проекте. Тратить его на чтение файлов целиком расточительно.Меня это раздражало. Написал инструмент. Что я сделал Написал два PHP-скрипта: buildGraph.php — сканирует проект и строит граф зависимостей в SQLite. Парсит PHP и JS: классы, методы, вызовы, импорты, наследование. Запуск инкрементальный — повторный проход обновляет только изменённые файлы за 100–200 мс. claudeSearch.php — CLI-интерфейс. Даёт AI точечный доступ к коду одной командой.

https://habr.com/ru/articles/1035206/

#ai #claude_code #deepseek

#deepseek #claude_code #ai

Habr @[email protected] · 2026-05-14 · 12:42 UTC

Claude ест токены впустую, но я его прокачал

В материале расскажу вам о инструменте для AI-ассистента работающего CLI на PHP + SQLite. Который парсит проект, строит графы зависимостей и даёт Claude точечный доступ к коду: конкретный метод, поля класса, цепочка наследования, все SQL-запросы к таблице — одной командой, без чтения файлов целиком. Сейчас поддерживает Go , PHP и JavaScript, позже добавлю и C.ссылочка на гитхаб внизу) Claude знает структуру проекта — но недостаточно хорошо Claude Code читает CLAUDE.md , понимает архитектуру, знает какие файлы за что отвечают. Но когда доходит до дела — всё равно читает файлы целиком. Нужен один метод — читает весь класс. Нужно найти где вызывается функция — читает директорию за директорией. Контекст тает, а реальной работы ещё не было. К тому моменту как он добрался до ответа, контекст уже наполовину занят файлами которые я и сам мог открыть.Или другой сценарий: нужно понять какие поля у сущности. Claude читает файл целиком, хотя там нужны только первые 20 строк с полями и конструктором.Контекстное окно — главный ресурс при работе с AI на большом проекте. Тратить его на чтение файлов целиком расточительно.Меня это раздражало. Написал инструмент. Что я сделал Написал два PHP-скрипта: buildGraph.php — сканирует проект и строит граф зависимостей в SQLite. Парсит PHP и JS: классы, методы, вызовы, импорты, наследование. Запуск инкрементальный — повторный проход обновляет только изменённые файлы за 100–200 мс. claudeSearch.php — CLI-интерфейс. Даёт AI точечный доступ к коду одной командой.

https://habr.com/ru/articles/1035206/

#ai #claude_code #deepseek

Habr @[email protected] · 2026-05-13 · 12:22 UTC

Вы пустили ИИ-агента в репозиторий, теперь разбираемся, что он может сломать

В феврале 2026 года Claude Cowork стирает 15 лет семейных фотографий одной командой. За полгода до этого, в августе 2025-го, случился кейс Nx supply chain: малварь впервые в истории использует локальные ИИ-CLI как инструмент разведки. В марте этого года Google Cloud Threat Horizons H1-2026 подтверждает: часть украденных в Nx токенов используется кампанией UNC6426 для перехода CI/CD → cloud admin через злоупотребление OIDC. 72 часа от первого коммита до админских прав в AWS. Всё это примеры того, что может происходить, когда у ИИ-агента есть руки и мы забываем, на чьей машине эти руки действуют. Данная статья предназначается для неравнодушных инженеров, AppSec, DevSecOps специалистов и всех тех, кто хоть раз запускал агента у себя на машине. Запрещать агентов в контуре бесполезно, отказываться от них самому глупо, но чем они так опасны? Сперва развеем туман неясности, построим модель угроз, собранную на реальных инцидентах и опубликованных CVE, а после будут конкретные рекомендации, как ограничить агента песочницей без ущерба для эффективности разработки. И как запускать --dangerously-skip-permissions без страха.

https://habr.com/ru/companies/pt/articles/1030532/

#ИИагенты #безопасность #OWASP #supply_chain #Claude_Code #prompt_injection #DevSecOps

#devsecops #prompt_injection #claude_code #supply_chain #owasp #безопасность

Habr @[email protected] · 2026-05-13 · 12:22 UTC

Вы пустили ИИ-агента в репозиторий, теперь разбираемся, что он может сломать

В феврале 2026 года Claude Cowork стирает 15 лет семейных фотографий одной командой. За полгода до этого, в августе 2025-го, случился кейс Nx supply chain: малварь впервые в истории использует локальные ИИ-CLI как инструмент разведки. В марте этого года Google Cloud Threat Horizons H1-2026 подтверждает: часть украденных в Nx токенов используется кампанией UNC6426 для перехода CI/CD → cloud admin через злоупотребление OIDC. 72 часа от первого коммита до админских прав в AWS. Всё это примеры того, что может происходить, когда у ИИ-агента есть руки и мы забываем, на чьей машине эти руки действуют. Данная статья предназначается для неравнодушных инженеров, AppSec, DevSecOps специалистов и всех тех, кто хоть раз запускал агента у себя на машине. Запрещать агентов в контуре бесполезно, отказываться от них самому глупо, но чем они так опасны? Сперва развеем туман неясности, построим модель угроз, собранную на реальных инцидентах и опубликованных CVE, а после будут конкретные рекомендации, как ограничить агента песочницей без ущерба для эффективности разработки. И как запускать --dangerously-skip-permissions без страха.

https://habr.com/ru/companies/pt/articles/1030532/

#ИИагенты #безопасность #OWASP #supply_chain #Claude_Code #prompt_injection #DevSecOps

#devsecops #prompt_injection #claude_code #supply_chain #owasp #безопасность

Habr @[email protected] · 2026-05-13 · 12:22 UTC

Вы пустили ИИ-агента в репозиторий, теперь разбираемся, что он может сломать

В феврале 2026 года Claude Cowork стирает 15 лет семейных фотографий одной командой. За полгода до этого, в августе 2025-го, случился кейс Nx supply chain: малварь впервые в истории использует локальные ИИ-CLI как инструмент разведки. В марте этого года Google Cloud Threat Horizons H1-2026 подтверждает: часть украденных в Nx токенов используется кампанией UNC6426 для перехода CI/CD → cloud admin через злоупотребление OIDC. 72 часа от первого коммита до админских прав в AWS. Всё это примеры того, что может происходить, когда у ИИ-агента есть руки и мы забываем, на чьей машине эти руки действуют. Данная статья предназначается для неравнодушных инженеров, AppSec, DevSecOps специалистов и всех тех, кто хоть раз запускал агента у себя на машине. Запрещать агентов в контуре бесполезно, отказываться от них самому глупо, но чем они так опасны? Сперва развеем туман неясности, построим модель угроз, собранную на реальных инцидентах и опубликованных CVE, а после будут конкретные рекомендации, как ограничить агента песочницей без ущерба для эффективности разработки. И как запускать --dangerously-skip-permissions без страха.

https://habr.com/ru/companies/pt/articles/1030532/

#ИИагенты #безопасность #OWASP #supply_chain #Claude_Code #prompt_injection #DevSecOps

#devsecops #prompt_injection #claude_code #supply_chain #owasp #безопасность

Habr @[email protected] · 2026-05-13 · 12:22 UTC

Вы пустили ИИ-агента в репозиторий, теперь разбираемся, что он может сломать

В феврале 2026 года Claude Cowork стирает 15 лет семейных фотографий одной командой. За полгода до этого, в августе 2025-го, случился кейс Nx supply chain: малварь впервые в истории использует локальные ИИ-CLI как инструмент разведки. В марте этого года Google Cloud Threat Horizons H1-2026 подтверждает: часть украденных в Nx токенов используется кампанией UNC6426 для перехода CI/CD → cloud admin через злоупотребление OIDC. 72 часа от первого коммита до админских прав в AWS. Всё это примеры того, что может происходить, когда у ИИ-агента есть руки и мы забываем, на чьей машине эти руки действуют. Данная статья предназначается для неравнодушных инженеров, AppSec, DevSecOps специалистов и всех тех, кто хоть раз запускал агента у себя на машине. Запрещать агентов в контуре бесполезно, отказываться от них самому глупо, но чем они так опасны? Сперва развеем туман неясности, построим модель угроз, собранную на реальных инцидентах и опубликованных CVE, а после будут конкретные рекомендации, как ограничить агента песочницей без ущерба для эффективности разработки. И как запускать --dangerously-skip-permissions без страха.

https://habr.com/ru/companies/pt/articles/1030532/

#ИИагенты #безопасность #OWASP #supply_chain #Claude_Code #prompt_injection #DevSecOps

#ииагенты #безопасность #owasp #supply_chain #claude_code #prompt_injection

Habr @[email protected] · 2026-05-13 · 10:02 UTC

Auto Dream переписывает вашу память в Claude Code. Откатить нельзя. Поэтому я собрал cc-janitor

# Auto Dream переписывает вашу память в Claude Code. Откатить нельзя. Поэтому я собрал cc-janitor Продолжение серии. Предыдущие части: [антирегрессионный сетап]( https://habr.com/ru/articles/1013330/ ) (топ-5 за сутки), [иерархический контекст]( https://habr.com/ru/articles/1024878/) Два месяца ежедневной работы в Claude Code оставляют свалку. Сотни старых сессий на гигабайты. Правила permissions, размазанные по пяти файлам settings.json — половина уже неактуальна. CLAUDE.md и memory-файлы, которые сами себе противоречат. Хуки, которые молча сломались неделю назад. А потом Anthropic выкатил Auto Dream. Auto Dream — это LLM, который между сессиями переписывает вашу проектную память. Консолидирует, сокращает, реорганизует. Агрессивно. Без отката. Без показа что именно изменилось. Рекомендация самого Anthropic: «сделайте бэкап ~/.claude/ перед включением». Инструмента, который делает этот бэкап — в экосистеме Claude Code не существовало. А еще почти не существует универсальных инструментов для чистки и обслуживания вашей CC среды. Мне нужен был бэкап. Мне также нужна была чистка. За шесть дней я собрал cc-janitor — детерминированный TUI/CLI, который аудитирует, чистит и оборачивает Auto Dream наблюдаемыми, откатываемыми снапшотами. ## Почему «детерминированный» — ключевое слово В пайплайне очистки cc-janitor нет LLM. Auto Dream использует LLM — именно поэтому он может перечистить, галлюцинировать противоречия или потерять провенанс. cc-janitor использует regex, подсчёт совпадений в транскриптах, парсинг frontmatter и SHA-256 отпечатки. Если правило неоднозначно — инструмент не действует, а поверхностно показывает проблему. Решение принимаете вы.

https://habr.com/ru/articles/1034614/

#Claude_Code #Python #DevTools #Auto_Dream #open_source #ai #tools #lifehack

#lifehack #tools #ai #open_source #auto_dream #devtools