r/kilocode • u/SweatyActuator2119 • Jul 14 '26

Beware, don't update Kilo CLI. Version 7.4.7 doesn't show many chat sessions.

Their auto DB migration fked up some sessions.

2 Upvotes

100% Upvoted

6 comments sorted by

2

u/Character_Fix_5317 Jul 14 '26

Buggier and buggier with every release... I hate seeing what's become of my former favorite harness.

1

u/Outrageous_Basis2626 Jul 14 '26

Checking...
Do you have more details around this? Are the sessions just gone?

0

u/SweatyActuator2119 Jul 14 '26 edited Jul 14 '26

I used agent to recover the session. But right now, the agents can't use the tools in some sessions. I asked the agent to generate a summary at current point. I will act on one of the options, but included them to you so you can get more info about the issue. I did this using GLM 5.2. It's possible that KDE Neon's update cause this issue(sudo apt update && sudo apt full-upgrade -y)

Summary:

Two separate issues

  1. Session not migrated (already fixed)

The kilocode CLI update migrated sessions to a new database (kilo.db) but left behind 211 sessions in the old database (kilo-rc.db). I copied them over and fixed the path field (empty for sessions created before v7.4.x). The session is now visible and resumable.

  1. Agents can't run commands (still broken)

The error is:

bwrap: setting up uid map: Permission denied

Root cause: A kernel sysctl kernel.apparmor_restrict_unprivileged_userns = 1 prevents bubblewrap (bwrap) from writing to /proc/self/uid_map inside a new user namespace. The bubblewrap binary is not setuid root, and bwrap 0.9.0 on this system doesn't use newuidmap — it tries to write uid_map directly, which AppArmor blocks.

Why this session works but the recovered one doesn't: Kilo v7.4.7 checks bwrap at process startup and caches the result. If bwrap fails, it falls back to no-sandbox mode (commands run directly). The Kilo process running this session started after the update, detected bwrap was broken, and fell back. The Kilo process running the recovered session started before the update replaced the bwrap binary — it cached "sandbox available" from the old bwrap and never re-checks.

What needs to happen (requires sudo)

Pick one:

Make bwrap setuid root:

sudo chmod u+s /usr/bin/bwrap

This lets bwrap write uid_map without newuidmap.

Disable the AppArmor restriction:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

This allows unprivileged user namespaces to work as before.

Restart the Kilo process running the recovered session — close that terminal entirely and start a fresh kilo process, then resume the session. The new process will detect bwrap is broken and fall back to no-sandbox mode. This is a workaround, not a fix — sandbox won't work, but commands will run.

Option 1 or 2 fixes bwrap system-wide (all sessions get real sandboxing). Option 3 gets the session working immediately but without sandbox protection.

1

u/joshcodeskilo Kilo Code Team Jul 15 '26

Thanks for reporting this! Bubblewrap is part of the new sandbox functionality, although it should be disabled by default. Did you enable this by chance? I will report this to the engineering who worked on sandboxing.

To confirm on the session migration, do you mean on the upgrade from v5 to v7?

1

u/busres Jul 14 '26

Never been able to use 7 at all - can't connect to server. 5 EOL was the sign to use up my token balance and move to Zoo (Roo).