Case Files

On first boot you reach the Kodachi-branded LightDM login (default credentials kodachi / Security4All; use the greeter's keyboard/language selector first if needed), then the dark XFCE desktop loads with the Conky real-time system monitor. The Kodachi Dashboard then auto-launches and shows a welcome screen for terms acceptance, dashboard mode selection (Full, Lite or Circle), optional startup privacy settings and network detection, and it offers AutoShield as the guided first-boot setup route. Automatic first-boot operations include binary deployment verification, DNSCrypt auto-configuration, online authentication, system status collection and Conky initialization. AutoShield is the Dashboard's countdown-driven setup wizard, not a separately launched program.

Yes. Every Kodachi security service is a standalone CLI-first Rust binary, so the full suite works headless with no dashboard. The Kodachi Terminal Server edition is terminal-only by design (no GUI at all), built for hardened servers and headless deployments, and exposes the same binaries (health-control, tor-switch, dns-switch, routing-switch, workflow-manager, and more) directly from the command line.

Yes. On the desktop edition the "Kodachi Rofi Actions" menu gives keyboard-driven access to security operations, network controls, services, and utilities without using the mouse. The launcher is bound to Ctrl+K (it runs /usr/local/bin/kodachi-rofi-actions). The broader application/rofi launcher is also bound to Super+R, Alt+F1, Alt+F3, Ctrl+Escape, and a tap of the left Super key. On the Terminal edition everything is driven from the shell.

It is a set of keyboard-driven Rofi menus installed to /usr/local/lib/kodachi-rofi/. The Actions menu is the primary dispatcher and opens sub-menus: Favorites (quick-launch tools), Network (VPN connect/disconnect, Tor toggle, DNS switching, routing mode), Services (start/stop/status for Tor, DNSCrypt, firewall), and Utilities (cleanup, MAC randomization, hostname change, panic triggers). Launch it with Ctrl+K.

Yes. On first login the AutoShield welcome script detects whether DNSCrypt has been configured (via a marker file), and if not it auto-configures encrypted DNS, retrying up to 3 times with short delays. It writes a marker so it does not reconfigure on later logins, and it auto-recovers if systemd-resolved hijacks DNS. You can force reconfiguration with kodachi-autoshield.sh --force-dns-setup.

Yes. Kodachi delivers a fully prepared, hardened environment with built-in privacy tools ready from the very first boot. On the Desktop edition the Kodachi Dashboard auto-launches at login and presents AutoShield, its guided first-boot wizard, which runs a multi-step security hardening sequence; you can re-open it any time from the dashboard header. The overview describes Kodachi as providing out of the box what would take most users months of setup to build correctly.

Yes. Kodachi 9 ships KAICS (an 8-binary plain-English CLI) and an ai-gateway for policy-firewalled agent execution. It uses a 7-tier engine (TF-IDF, ONNX, ONNX-Classifier, Local LLM, Mistral.rs, GenAI/Ollama, then Claude) and is offline-first, with optional cloud routing only via VPN or Tor. On Desktop, the AI Chat button is available in Circle, Lite and Full modes to explain commands or suggest sequences without leaving your tab.

Kodachi 9 provides 25 auto-documented Rust binaries plus bundled companion runtimes, covering routing, Tor, DNS, integrity, host security monitoring, health/emergency control, authentication and a local AI stack. On Desktop the Kodachi dashboard orchestrates 600 generated commands across 25 Rust binaries with no GUI freezing. The Terminal edition ships the same 28-binary pack in /opt/kodachi/dashboard/hooks/ (20 core + 8 AI); the Conky telemetry display itself is a Desktop add-on.

No. Kodachi is a hardened privacy and security operating system, not a standalone VPN provider. A VPN is only one component; Kodachi also bundles Tor routing, DNS leak protection, anti-forensics tools, multiple tunneling protocols, and hardened defaults. The docs explicitly say it should not be compared to a normal VPN subscription because it is an integrated OS-level stack rather than a single tunnel service.

Kodachi is a Debian 13-based distribution shipping failover VPN, Tor routing, DNS protection, encrypted crypto wallets, full-disk encryption utilities, a hardened browser, and an integrated dashboard, all working from first boot. The stated value is delivering out of the box what would otherwise take most users months of manual setup and trial-and-error to assemble and harden correctly.

Choose Desktop (full XFCE on Debian 13, ~5GB) for daily privacy-focused computing with a GUI. Choose Terminal (minimal live ISO, 2.4GB, Debian 13) for testing the toolchain, headless privacy deployments, or running a dedicated SOCKS proxy gateway on old hardware or a VM. Choose the Binary Suite to run the signed Rust binaries on an existing Debian-based system. All are free for personal use and share the same underlying privacy stack.

Yes. Run it as a live USB (no traces, nothing written to disk) or in a VM (VMware/VirtualBox/QEMU). The Terminal edition is explicitly described as a safe isolated environment to test the full binary suite without affecting your main system. Take a VM snapshot before experimenting so you can roll back.

If you are new, the best way to learn Kodachi is inside a virtual machine, not on your real hardware. Install VMware Workstation Pro (now free for personal use), then run two instances side by side: one booted from the live ISO and one installed into its own VM. Take a VM snapshot before you experiment so you can roll back to a clean state at any time, then play, test and learn as much as you want with zero risk to your host machine. This is how the developer runs it day to day. Only install Kodachi on bare metal (your physical drive) if you genuinely need it as your everyday daily-driver OS. For the safe-testing options see Can I try Kodachi safely without affecting my main system?, and for every supported run method see Can I run Kodachi purely from a USB or SSD?

Kodachi is built in the open: the Rust binaries, dashboard, and live-build tooling are on GitHub, so it can be read, built, and audited. Every Rust binary, ISO, and the binary tarball are cryptographically signed with a published public key, and a regularly refreshed signed warrant canary is maintained. It is built by a named maintainer, Warith Al Maawali (digi77.com), the same person since 2013, and is independently tracked on DistroWatch.

Kodachi is provided for legitimate privacy protection, security research, and educational purposes only and must not be used for illegal or criminal activities. Users are solely responsible for compliance with all applicable laws in their jurisdiction, and the developers disclaim all liability for misuse. Anyone intending unlawful use is told to discontinue use immediately.

No tool guarantees absolute anonymity. Kodachi gives a strong integrated stack (VPN, Tor, proxies, DNS controls, anti-leak enforcement) and hardened defaults from first boot, but real anonymity still depends on your configuration and behavior - which routing mode you select and your OPSEC. The docs frame it as giving real control and protection and teaching better habits, not as automatic, absolute anonymity.

No. The free tier uses the same binaries, the same OS-level hardened stack, and the same updates as the paid plans. The only differences are backend infrastructure quality, commercial usage rights, and priority support - not the software or its security capabilities.

No. There is no registration, no account, and no personal data required - you can authenticate and even pay (via Monero) with no email or phone number. The design goal is to never create useful data in the first place: client traffic is encrypted, the VPS exit nodes are regularly wiped and replaced, and the master node keeps no usage logs, so even in a worst-case compromise there is very little of value to obtain. The same hardening is applied across the client, the VPS nodes, and the master node - a privacy OS is only as good as its backend.

Authentication is what unlocks Kodachi's service-backed features: the built-in VPN nodes, the proxy pool, encrypted DNS and the other cloud-assisted tools. You do not log in by hand, the dashboard signs in automatically as it loads, silently and with no username or password to type, so for most users it simply happens in the background.

It serves two goals that directly benefit you. First, it separates free from premium access, which is what lets the project offer a capable free tier and keep the lights on. Second, it is an anti-abuse gate: by blocking bots, scrapers and anyone hammering the infrastructure, it keeps the shared free nodes fast and usable for everyone. Crucially, it needs no personal data at all, no email, no phone and no name, so it controls access without identifying you (see is authentication tracking me).

No. Authentication exists to distinguish paid from free users, limit abuse, and protect the project from malicious actors - not to monitor you. You authenticate without any personal details (no email, no phone), so your anonymity is preserved. The OS itself runs without authorizing, but the service-backed features won't fully work until you authenticate; it is an anti-abuse gate, not surveillance.

Kodachi's code is published on GitHub at https://github.com/WMAL/kodachios. The full source of versions prior to v9 is public, including Kodachi 8.27 (the last of the 8.x series) together with the full dashboard source. Source is released after major changes or shifts so users can study how Kodachi evolved over time. The Kodachi 9 bash scripts that ship inside the ISO are also hosted on that same GitHub repository.

Study the published code and its history on GitHub at https://github.com/WMAL/kodachios. The full source of pre-v9 releases such as Kodachi 8.27 and the complete dashboard source are there, and the project publishes source after major changes so you can trace how the system evolved across versions. The Kodachi 9 bash scripts bundled in the ISO are also hosted in that repository, so you can read exactly what runs at boot and during setup.

Kodachi is created and maintained by Warith Al Maawali, an independent security engineer who has developed it as a one-person project under the same name since 2013. He builds it openly under his real identity rather than as an anonymous team, and also runs digi77.com. You can see who he is and follow the work directly on LinkedIn at https://om.linkedin.com/in/warith1977 and on X (Twitter) at https://x.com/warith2020, and the full project history is on GitHub at https://github.com/WMAL/kodachios.

Yes. Kodachi publishes a regularly refreshed warrant canary at /tools/warrant.html. A warrant canary is a routinely updated statement that no secret legal orders or gag requests have been received; if it stops being updated or its wording changes, treat that as a warning sign. It is part of Kodachi's transparency model alongside the open source code and the cryptographically signed releases.

It is a short, plain-language agreement, not data collection and not registration. Nothing is sent anywhere; accepting it only writes a local acceptance file. Its real purpose is to protect the developer, and that protection matters precisely because Kodachi is not run by an anonymous team. Most privacy projects hide behind pseudonyms. Kodachi is built openly by Warith Al Maawali under his real identity, which is exactly what lets you verify and trust who is behind it. The trade-off of using a real name is real exposure: if someone uses Kodachi to commit a crime, the author could be wrongly dragged into it. The terms make the boundary explicit. They state that Kodachi's purpose is to protect privacy, that it must not be used for illegal activity, that you should stop immediately if your intent is unlawful, that the developer disclaims all liability for any illegal actions committed by users, that you agree to use it responsibly and legally, that your own data security remains your responsibility, that the software is provided as-is with no warranties, and that the terms may be updated so you should review them. In short, the acknowledgement exists so every user understands that responsibility for how Kodachi is used rests with the user, not with the person who chose to put his real name on a privacy tool.

Kodachi supports both legacy BIOS and UEFI - the documented boot support is 'BIOS + UEFI + Secure Boot'. UEFI Secure Boot is supported through signed GRUB and shim packages that are bundled in the ISO, so the bootloader integrity is verified before execution and no internet download is needed during installation. For Secure Boot systems, the dedicated Kodachi Secure Boot Mode entry enforces module signing and lockdown policies. Either firmware type works; only the Secure Boot security-score check is skipped on BIOS-only machines (it drops out of the maximum rather than counting as a failure).

No - Kodachi ships signed GRUB and shim packages so it boots normally with UEFI Secure Boot enabled, and there is a dedicated Secure Boot Mode entry for trusted boot chains. The only caveat is that with Secure Boot on, the kernel enforces module signatures, so unsigned out-of-tree add-ons such as the Tirdad DKMS module will not load. If you specifically need such an unsigned module, disable Secure Boot in your firmware settings or reboot into a non-signature-enforcing mode like Kodachi Live, Persistent, Encrypted Persistence, CPU Hardened, Forensics, or DMA Protection.

Yes. Kodachi Desktop includes a Debug Collector that gathers system diagnostics (boot logs, hardware specs, network configuration, Kodachi service status, and more) into a single zip on your Desktop. Run it interactively with curl -sSL /apps/os/install/kodachi-debug-collector.sh | sudo bash, or skip the category menu and collect everything with curl -sSL /apps/os/install/kodachi-debug-collector.sh | sudo bash -s -- --all. The output is saved as ~/Desktop/kodachi-debug-*.zip.

The Debug Collector does NOT capture IP addresses, passwords, browsing data, or personal files, and it automatically redacts WiFi credentials and MAC addresses. You can also deselect specific categories from the interactive menu before collection starts if you want to exclude anything else. After it produces ~/Desktop/kodachi-debug-*.zip, upload that file to your preferred file-sharing service and share the link with the support team on Discord (https://discord.gg/KEFErEx) or via the contact form at /docs/support.html.

Yes. You never need to reinstall the OS to update binaries. First stop the Permission Guard daemon so it does not cause file-permission conflicts during the update: sudo permission-guard --stop-daemon (or sudo online-auth disable-permission-guard), then verify it is stopped with sudo permission-guard --daemon-status (or sudo online-auth permission-guard-status). Then run the binary installer with no sudo: curl -sSL /apps/os/install/kodachi-binary-install.sh | bash, followed by the dependencies installer with sudo: curl -sSL /apps/os/install/kodachi-deps-install.sh | sudo bash, and finally confirm with integrity-check check-version. You can also trigger these updates from the XFCE panel - see Can I update Kodachi without downloading a new ISO?

Permission Guard is a runtime daemon that monitors and enforces file permissions, so if it is running while the installer overwrites binaries it can cause file-permission conflicts during the update. The simplest documented approach is to log out, run the update scripts, then log back in; alternatively stop the daemon explicitly with sudo permission-guard --stop-daemon or sudo online-auth disable-permission-guard and confirm it is down with sudo permission-guard --daemon-status. If you installed to a custom path, call the binary at that path, e.g. sudo /custom/path/permission-guard --daemon-status instead of the default /opt/kodachi/dashboard/hooks/permission-guard.

Run integrity-check check-version to see the binary version, or ip-fetch --version for a quick single-binary check. After updating, the documented verification step is integrity-check check-version, and you can also use sudo integrity-check check-all to verify integrity, signatures, and version together. Note that automatic updates are planned for future releases; for now updates are manual via the binary and dependency installer scripts.

Yes. The supported run/install methods are: Live USB (boot from a USB drive with no installation and no traces left), Persistent Storage (enable persistence so configuration survives reboots), Bare Metal install to disk (maximum performance, including the full-disk-encryption boot-nuke-compatible install), and Virtual Machine (VMware, VirtualBox or QEMU for testing or isolation). The Kodachi binaries can additionally run inside Docker. Recommended USB writing tools documented are Ventoy, Rufus and balenaEtcher.

Yes. Kodachi follows the Parrot OS pattern: network is disabled during installation in all preseed files, UEFI Secure Boot packages are bundled in the ISO, and the text installer is fully unattended with no network, locale or keyboard prompts. This means faster, reliable, offline installation that works in isolated or air-gapped environments. Network is configured automatically on first boot afterwards.

By design. The GRUB-launched text installer deliberately disables the keyboard-layout prompt and defaults to US English so the install is fully unattended and offline-capable - all keyboard layouts are still included on the ISO, and you can switch to your layout at any time after installation with no issues. If you want to pick your layout and locale during installation, boot into the live desktop and use the Calamares graphical installer instead, which exposes those options.

Yes. The Kodachi binaries can be installed standalone on an existing Debian-based system (default install path /opt/kodachi/dashboard/hooks) and even run inside Docker/Docker Compose, which both default to /opt/kodachi/dashboard/hooks. This is useful for testing or integrating specific tools (routing-switch, dns-switch, tor-switch, etc.) into your own workflow without booting the full Kodachi OS.

Use the Debian text installer from the ISO GRUB menu, not the Calamares GUI encrypted path. Boot the ISO, open 'Advanced options & fallback modes...', and choose 'Install Kodachi (Text + Full Disk Encryption, Boot-Nuke Compatible)' or the equivalent unattended encrypted entry. These keep /boot outside LUKS so the passphrase prompt stays in initramfs, which cryptsetup-nuke-password requires. Calamares is fine for standard installs but its encrypted path can put the first LUKS prompt in GRUB, which blocks boot-nuke.

This is intentional Parrot-style behavior: the text installer launched from the GRUB menu disables keyboard, locale, and network prompts so installation is fully unattended, fast, and works offline/air-gapped with no DHCP dependency. The keyboard defaults to US English during setup only (preseed sets xkb-keymap us, netcfg/enable false); all layouts ship in the system and you switch after first boot. To choose layout/locale during install, use the Calamares graphical installer from the live session instead.

The VM is using a non-US keyboard layout (often UK), which swaps @ and ". Fix it at the hypervisor: for QEMU CLI add '-k en-us'; in virt-manager set the Display Spice/VNC keyboard layout to English (US); in VirtualBox use Settings > General > Advanced > English (US) or 'VBoxManage modifyvm "Kodachi VM" --keyboard-layout "English (US)"'.

VirtualBox does not enable EFI by default, so a UEFI boot fails unless you turn it on. In the VM settings enable EFI, allocate 4GB+ RAM, set the network to NAT or Bridged, and attach the ISO to the virtual optical drive. If issues persist, use a BIOS boot or the Advanced menu hardware-fallback entries (nomodeset, noapic, GPU compatibility).

The ISO is BIOS + UEFI compatible and ships signed GRUB and shim, so Secure Boot is supported. If a strict Secure Boot system refuses other entries, pick the 'Kodachi Secure Boot Mode' entry, which uses signed modules (module.sig_enforce=1) and lockdown=confidentiality designed for Secure Boot enforcement. For display/hardware boot failures, use 'Advanced options & fallback modes...' which offers nomodeset, noapic, legacy NIC naming, and GPU compatibility modes.

This is usually a bad or wrong USB write. The recommended method is dd (Linux: 'sudo dd if=linux-kodachi-...-amd64.iso of=/dev/sdX bs=4M status=progress oflag=sync') - confirm the device with 'lsblk' first because dd overwrites the whole target drive. On Windows use Rufus or Etcher, and always verify the ISO checksum before writing so you don't flash a corrupted image.

A mismatch means the file is corrupted or incomplete (interrupted download or bad USB write) or, rarely, tampered with - do not install it. Re-download from the official Kodachi download page and re-check the hash, or use the browser-based File Verification tool which checks against all official Kodachi checksums automatically. Only proceed once the hash matches exactly.

No. Signature verification warnings are informational and the installer deliberately continues. Security is enforced by three independent layers: the RSA-4096 package signature, the SHA256 package checksum, and per-binary signatures. Only if all three fail for a given binary should you re-download the package.

The minimal Debian desktop install does not include curl while live ISOs do, and the Kodachi scripts are fetched with curl. Install it first with 'sudo apt-get update && sudo apt-get install -y curl', then re-run the installer; the dependency script then pulls in the other essentials like procps and psmisc.

The install scripts download the package from the Kodachi cloud host, so they need connectivity at install time. Test connectivity to the Kodachi host; if it works retry, otherwise download the kodachi-binaries-v9.0.1 tarball manually with wget on any machine and follow the Manual Binary Installation steps to extract it into /opt/kodachi/dashboard/hooks yourself.

Your account simply isn't in the sudo group, which the dependency installer requires to install system packages. Switch to root with 'su -', run 'usermod -aG sudo YOURUSERNAME', exit, then log out and back in for the group change to take effect. Then run the binary installer (no sudo) and the dependency installer with sudo.

The binary files lost their executable bit, usually after a manual extraction or copying without preserving permissions. Restore it with 'chmod +x /opt/kodachi/dashboard/hooks/*'. If you installed manually, make sure you ran the chmod step on all top-level files in the hooks directory.

Permission Guard is a runtime daemon that restores file permissions, so if it runs while you overwrite binaries it fights the update and causes conflicts. Stop it before updating: the simplest way is 'sudo online-auth logout', or 'sudo permission-guard --stop-daemon'. Verify with 'sudo permission-guard --daemon-status', run both update scripts, then log back in. For non-default install paths, call the binary at its real location. This is by design, not a bug - Permission Guard restores correct ownership across critical Kodachi paths; for normal use leave it running and only stop it for installs/updates, restarting it afterward.

In a VM, take a snapshot before testing so you can roll back, use NAT networking for the VPN/Tor chain workflows, and expect a lower raw security score because live/VM sessions skip disk-encryption checks (not a defect). For Docker, the dependency script needs procps and psmisc plus curl/wget/openssl present first, contrib/non-free repos enabled, and debconf set noninteractive (with resolvconf linkify disabled) or the build hangs - install those in an earlier layer as the documented Dockerfile shows.

Re-authenticate cleanly: 'sudo online-auth logout' then 'sudo online-auth authenticate' (use --relogin for long sessions). Check whether you are actually blocked with 'online-auth check-if-blocked'. Note that logout also stops Permission Guard - the recommended first step before updates - so a failed-auth state is sometimes just a side effect of an interrupted update.

rsyslog was added to the Terminal package list specifically so persistent text logs survive crashes, shutdowns, and kernel issues by mirroring to /var/log/syslog. It is intentional and useful for diagnosing boot/crash problems - leave it installed; do not remove it if you want post-crash diagnostics.

No, and it does not need to. b43-fwcutter and broadcom-sta-dkms are installed, but the actual b43/b43legacy firmware blobs are already pre-extracted into the ISO at build time and shipped under /lib/firmware - so Broadcom WiFi works offline with no network fetch. The network-dependent firmware-b43-installer packages were deliberately excluded and replaced with empty dummy packages so the offline ISO build does not break.

Use Kodachi's browser-based File Verification tool at /docs/security/file-verify.html. It computes the hash locally in your browser and compares it against the official published checksums, and can also verify a .sig signature - nothing about your file is uploaded. The same tool works for individual binaries and the binary tarball, not just the ISO.

Yes. The Rust binaries are production-validated on Debian 12 (Bookworm), Debian 13 (Trixie) and Ubuntu 22.04+, and because they are highly portable they also run on most other modern Linux distributions. Any difficulty is almost always a missing system package dependency rather than the binaries themselves - deps-checker identifies and installs what's needed.

Both editions use username kodachi with password Security4All. The kodachi account has passwordless sudo, while direct root login is disabled and does not use this password. Change the password after installing for any persistent or installed system.

Partly: yes for the binaries and packages, no for the deeper system image. The XFCE panel includes two update launchers you can just click - "Kodachi Deps Update" runs /usr/local/bin/kodachi-deps-install, which pulls the latest dependency and Kodachi binary installer from kodachi.cloud, and "Kodachi System Update" runs apt-get full-upgrade for the Debian packages. These refresh the Rust security binaries and OS packages in place. They do NOT re-apply Kodachi's deeper customizations baked into the image - the hardening configs, AppArmor profiles, overlays, themes and system integration - nor do they update the bundled browser. To have the very latest end to end, installing the new ISO is always recommended. Tip: stop Permission Guard before running the updaters (sudo online-auth logout) so it does not fight the file replacement. For the command-line installer method, see Can I update the Kodachi binaries without reinstalling the OS?

Yes, so back up first. The live ISO itself runs entirely from RAM and writes nothing to your disk, but the moment you choose to install Kodachi to a drive (either the Calamares GUI installer or the text Full Disk Encryption installer), the target partition is formatted and whatever was on it is erased. A full-disk-encryption install replaces the entire disk. Because this is a live ISO and the install step is destructive, copy anything you care about to a separate drive before you begin. Use Kodachi's built-in Backup & Restore tool for this, see How do I back up my files before installing a new Kodachi ISO?, and if you need boot-time LUKS nuke pick the right installer per I need boot-time LUKS nuke - which installer should I use?. If you only want to try Kodachi without touching your existing system, run it as a live USB or in a VM instead, see Can I try Kodachi safely without affecting my main system?

Use Kodachi's built-in Backup & Restore tool (kodachi-backup), available on both the Desktop and Terminal editions. It makes an encrypted, versioned backup of your personal data with restic. On the Desktop edition open Settings and select the Backup tab; on the Terminal edition run kodachi-backup backup --target /path/to/drive. LUKS, VeraCrypt/TrueCrypt, and other dm-crypt volumes are detected automatically; by default unrecognised (unencrypted) drives are refused, but you can opt in via "Allow unencrypted destination" in the GUI or --allow-unencrypted on the CLI (restic still encrypts the backup with your passphrase, only the drive's full-disk-encryption layer is absent). The repository passphrase is never stored. It backs up your DATA only (Documents, Downloads, Pictures, Videos, Music, Desktop, Public, Templates, plus ~/.gnupg, ~/.ssh, password stores and the LibreWolf profile) and deliberately excludes desktop and system configuration (~/.config, ~/.cache, ~/.local, ~/.kde), so restoring onto the newer ISO can never break the fresh desktop. You can also back up custom folders and crypto wallets: use the Add custom folder control in the Backup tab (or kodachi-backup add-path --path <dir> on the CLI), and Monero, Bitcoin Core, Electrum, and Wasabi wallets are auto-detected and listed when present on disk. After installing the new ISO, open Backup & Restore (or run kodachi-backup restore --target /path/to/drive) and your files are extracted into a ~/Restored-<date> staging folder by default, leaving the new system untouched.

The GRUB menu has 8 main entries organized by security tier (Tier 1 lightest to Tier 5 strongest): Kodachi Live (Tier 1, hotkey L), Kodachi Persistent (Tier 2, P), Kodachi Encrypted Persistence (Tier 3, E), Kodachi CPU Hardened (Tier 3, C), Kodachi Maximum Privacy (Tier 4, M), Kodachi Secure Boot Mode (Tier 4, S), Kodachi Forensics Mode (Tier 5, F), and Kodachi Full Hardening (Tier 5, H). An 'Advanced options & fallback modes' submenu (hotkey A) adds DMA Protection, Hardened Malloc, Full RAM mode, Performance Balanced, plus hardware fallbacks (nomodeset, noapic, legacy NIC names, GPU/VESA modes), text-mode fallback, installer entries, and utilities like Memtest86+ and media integrity check. The first entry, Kodachi Live, is the default and the fastest to boot.

For most people the default Kodachi Live (Tier 1) is the right choice: it has a low RAM footprint, the fastest boot, and is ideal for testing, demos, and hardware compatibility checks. If you want to save changes between sessions on trusted hardware, use Kodachi Persistent (Tier 2); if you want that data encrypted, use Encrypted Persistence (Tier 3, LUKS-protected). Stronger profiles lower in the menu enable extra security controls and can boot slower or cause some services to fail, so only move up a tier when you actually need the extra hardening.

Kodachi Persistent (Tier 2, hotkey P) saves your changes to a persistence volume without encryption, which keeps it fast and low-overhead but means the data is readable if the media is lost or seized. Encrypted Persistence (Tier 3, hotkey E) stores the persistence volume inside a LUKS-encrypted container, so you are prompted for a password at boot and your saved data stays protected at rest. Encrypted Persistence trades a slightly slower, moderate boot for password-protected long-term storage; choose it when persistence data must remain confidential.

Use Kodachi Full Hardening (Tier 5, hotkey H) for high-threat or adversarial environments: it enables every mitigation including module signature enforcement, integrity lockdown, IOMMU/DMA protection, and CPU mitigations, at the cost of the slowest boot and a real chance that some services or hardware will not work. Use Kodachi CPU Hardened (Tier 3, hotkey C) specifically for CPUs vulnerable to Spectre/Meltdown-class speculative-execution attacks, especially on legacy or cloud hardware. For everyday privacy with good speed, stay on Live, Persistent, or Encrypted Persistence - the docs note a score of 50-65 with VPN, DNSCrypt and firewall active is already more secure than 99% of operating systems.

Kodachi Forensics Mode (Tier 5, hotkey F) is designed for forensic analysis of other machines: it boots fully into RAM so it never touches the target machine's disks, and your own session leaves no trace behind, making it suited to volatile-memory analysis and trace-free incident work. It has a high RAM footprint because it runs entirely in memory. Note it does NOT wipe memory on shutdown by default - enable that explicitly with sudo health-control ram-wipe-enable or via the Dashboard. It also disables the IPv6 stack at the kernel level, so the Dashboard cannot re-enable IPv6 without rebooting into a lower tier.

Kodachi Maximum Privacy (Tier 4, hotkey M) is a RAM-only session focused on anti-tracking: debug hooks are disabled, the session runs fully in memory, and memory is wiped on shutdown, making it good for sensitive privacy and anonymity tasks. Because it runs entirely in RAM it has a high memory footprint, though it still boots fast. Like Forensics and Full Hardening, it disables IPv6 at the kernel level (ipv6.disable=1), so the Dashboard IPv6 toggle cannot bring IPv6 back without a reboot into a Tier 1-3 entry - pick a lower tier if you need runtime IPv6 control.

Kodachi Secure Boot Mode (Tier 4, hotkey S) enforces signed kernel modules and applies lockdown policies (lockdown=confidentiality, module.sig_enforce=1) for systems running with UEFI Secure Boot enabled and trusted boot chains. It has a moderate RAM footprint and moderate boot speed. Be aware that on this mode the kernel refuses unsigned out-of-tree modules by design, so add-ons like the Tirdad unsigned DKMS module will correctly show as blocked - that is expected behavior, not a bug.

Open 'Advanced options & fallback modes...' (hotkey A) at the boot screen for specialized and recovery entries: DMA Protection (Tier 4, IOMMU against DMA attacks), Hardened Malloc (Tier 3), Full RAM mode (Tier 2, hotkey R), and Performance Balanced (Tier 1). It also contains hardware-compatibility fallbacks (text/no-GUI mode, old NIC names, noapic, acpi=off, nomodeset, GPU/VESA fallbacks, maximum-compatibility), the text and unattended installer entries (including encrypted Boot-Nuke-compatible variants), and utilities like Memtest86+, 'Check disc for defects', chain-loading the first disk, and UEFI Firmware Settings.

Use the right boot tier and the right hardware. Kodachi Live (Tier 1) has the lowest RAM footprint and the fastest boot; RAM-resident modes like Maximum Privacy and Forensics and the heavier hardening tiers consume much more memory and stronger profiles can boot slower. The documented requirements are 4GB RAM minimum (8GB+ recommended) and 20GB free storage (40GB+ recommended); an SSD/NVMe and more RAM make the biggest difference, especially for RAM-only modes. In the Dashboard, turn on Performance mode (Settings) to disable all visual/glass/glow effects and animations at once on low-power hardware, and use the quick animations toggle when the UI feels heavy.

The documentation does not state any specific boot-time figure, so a fixed claim like 'under 30 seconds' is not something Kodachi publishes. Boot time depends on your hardware and the boot tier you pick: the docs describe Kodachi Live as the fastest profile, Persistent also fast, Encrypted Persistence and Secure Boot Mode moderate, and CPU Hardened and Full Hardening the slowest because they enable extra security controls. RAM-resident modes (Maximum Privacy, Forensics, Full RAM) are fast to start but need more memory. For the quickest boot, use Kodachi Live on an SSD with adequate RAM and avoid stacking heavy hardening features.

Yes, at two levels. On the Desktop edition, AutoShield is the easy guided automation - the Kodachi Dashboard's first-boot wizard that runs a configurable set of hardening steps with a countdown timer. For far more power and customization, the workflow-manager binary runs batch command sequences with conditional logic, pattern/JSON matching, retry logic, pause checkpoints, dry-run testing and JSONL telemetry. It ships with 96 ready-to-use built-in profiles in dashboard/hooks/config/profiles/ and supports unlimited custom workflows. On the Desktop Full dashboard you can also drag commands from any service tab into a queue, reorder them, and run them sequentially or in parallel.

Yes. The ai-scheduler binary is a cron-based task scheduler for automated Kodachi operations. It uses standard cron expressions, enforces a strict command whitelist for security, and stores tasks persistently so they survive service restarts. It is ideal for recurring security checks, Tor circuit rotations, DNS leak tests, and AI learning cycles. Run it with ai-scheduler (the daemon needs sudo for scheduled privileged commands).

Two. The Kodachi Desktop Edition is built on Debian 13 (Trixie) with an XFCE GUI, the Kodachi dashboard, Conky system monitor, LibreWolf browser and 10 dynamic application layers - the full graphical experience. The Kodachi Terminal Server is a headless, command-line-only build (a lightweight ~2.4GB ISO with no GUI bloat) optimized for testing, dedicated SOCKS proxy deployment and server operations. Both editions ship every binary pre-installed and configured.

Yes, with options to keep it light. The Terminal Server edition has no GUI at all and is the lightest choice for old or constrained hardware and headless servers. On Desktop, the Circle and Lite dashboard modes use roughly ~230MB RAM (versus ~380MB for Full), and you can cut more overhead by enabling the dashboard Performance mode (disables glass blur, glow and animations) and turning off the Conky overlay to free 3-8% CPU.

LibreWolf blocks .onion domains by default per RFC 7686. The simplest fix is to use Tor Browser, which handles .onion natively with its own built-in circuits and no system torrification needed. To use .onion in LibreWolf you must first torrify the system, then in about:config allow .onion and disable the built-in proxy, and add a top-priority SOCKS5 entry in the pre-installed FoxyProxy extension pointing at 127.0.0.1 with Proxy DNS enabled on the correct Tor instance SocksPort.

Tor Browser uses its own built-in independent Tor circuits, separate from system torrification, so it naturally shows a different exit than the system. Additionally, under load-balanced torrification the widget, browser, and integrity panel can each show a different genuine Tor exit at the same time because Kodachi runs multiple parallel Tor instances. This is expected, not a misconfiguration.

Those three top-tier hardening entries set the kernel flag ipv6.disable=1, so the IPv6 stack is never initialized and /proc/sys/net/ipv6/ does not exist. The dashboard and 'health-control ipv6-enable' work via sysctl, which cannot bring back a stack that was never created. Reboot into a lower-tier entry (Live, Persistent, Encrypted Persistence, CPU Hardened) where IPv6 is initialized and toggleable at runtime.

Stronger hardening profiles enable extra controls - module signing, kernel lockdown, IOMMU, anti-tracking, disabled debugfs - that can intentionally break some commands, services, or hardware detection, and they boot slower and use more RAM. This is expected fail-closed behavior. Reboot and pick a less restrictive profile such as 'Kodachi Live' (Tier 1), the lightest and fastest default.

Open Essentials > Actions > Network Recovery > Fix Internet Wizard and read the pre-fix badges. If the host is torrified, trust the HTTP connectivity check more than the ping check, because ICMP ping is unreliable through Tor. Run the normal queue first (full auto recovery, flush DNS, fallback DNS, fix DNS); if it still fails, expand Advanced Steps (recover routing, toggle DNS mode, restart DNSCrypt, or detorrify when Tor firewall rules are the blocker).

Use the Enable DNSCrypt row's chevron menu in AutoShield (or Essentials > DNS). Check DNS Status, then run Safe DNS Repair, which restores encrypted DNS without breaking active tunnels. Only if that fails use Forced DNS Repair, which resets all DNS config. Verify with a DNS Leak Test, and if Tor is active switch to Tor DNS to route DNS through Tor circuits.

systemd-resolved can take over the resolver and override DNSCrypt. AutoShield continuously verifies DNSCrypt is the active resolver and includes auto-recovery that detects the hijack and restores DNSCrypt, retrying configuration up to 3 times with short delays before falling back to direct DNS. If it stays broken, force reconfiguration with 'kodachi-autoshield.sh --force-dns-setup'.

On first login AutoShield creates a marker file 'results/dns-configured' in the hooks directory specifically so DNSCrypt setup does not re-run on every subsequent login. Because the marker exists, normal logins skip reconfiguration. Force it to run again with 'kodachi-autoshield.sh --force-dns-setup', which ignores the marker.

DNSSEC adds cryptographic signatures to DNS records so your resolver can verify that answers haven't been tampered with in transit. On Kodachi the encryption layer is dnscrypt-proxy, not systemd-resolved, so the canonical command is sudo dns-switch dnssec-on. This sets require_dnssec = true in /etc/dnscrypt-proxy/dnscrypt-proxy.toml and restarts dnscrypt-proxy automatically. With validation on, only signed upstream responses are accepted; unsigned responses are silently rejected, which can break resolution for domains that haven't deployed DNSSEC yet. Disable it with sudo dns-switch dnssec-off. Enabling DNSSEC earns +0.1 dns_privacy points in the health-control security score.

DoH encrypts DNS queries inside HTTPS to port 443, making them indistinguishable from regular web traffic and harder to block or intercept than plain DNS. It is functionally equivalent to DNS-over-TLS (DoT) but uses the standard HTTPS port. On Kodachi run sudo dns-switch dot-on, which sets doh_servers = true in /etc/dnscrypt-proxy/dnscrypt-proxy.toml and restarts dnscrypt-proxy to allow DoH-capable resolvers. Disable with sudo dns-switch dot-off. Do not bother editing /etc/systemd/resolved.conf on Kodachi, as systemd-resolved is typically inactive and won't affect live DNS traffic. Enabling DoH earns +0.2 dns_privacy points in the health-control security score.

AutoShield detected no internet connectivity and switched to offline mode. Online data (crypto prices, news, online authentication) needs to reach the Kodachi VPS; offline it shows placeholders and uses local DNS instead. All local features remain fully functional - restore connectivity and the data refreshes on the next periodic refresh cycle.

The core binaries install to /opt/kodachi/dashboard/hooks (or your --desktop/--path location), which is not on PATH unless the installer added it to ~/.bashrc (skipped with --skip-path or in a fresh shell). Verify with 'ls -la /opt/kodachi/dashboard/hooks/' and check $PATH, then run by full path, add the directory to PATH, or 'source /opt/kodachi/dashboard/hooks/kodachi-env.sh'. For permanent system-wide access run 'cd /opt/kodachi/dashboard/hooks && sudo ./global-launcher deploy'; 'global-launcher verify' checks deployment integrity.

No post-boot installation is required. firmware-b43-installer and firmware-b43legacy-installer are intentionally excluded because they fetch firmware over the network at install time, which would break the offline ISO build; instead the b43 and b43legacy firmware is pre-extracted on the build host (b43-fwcutter) and shipped in the ISO under /lib/firmware/b43/ and /lib/firmware/b43legacy/, and broadcom-sta-dkms is included for the proprietary wl driver. Kodachi also bundles firmware for Intel, Atheros/Qualcomm, Realtek, MediaTek and others. If WiFi still fails on a strict hardening profile, reboot into Live or Persistent for broader compatibility.

WiFi is commonly soft/hard-blocked by rfkill or put to sleep by power management. Run 'rfkill list' then 'sudo rfkill unblock wifi', bring the interface up, and check 'dmesg | grep -i firmware' for missing firmware. For frequent drops disable radio power saving and verify the regulatory domain with 'iw reg get', since a wrong country code restricts channels.

The default 'Kodachi Live' mode has no persistence by design - it is a throwaway RAM session that leaves no traces. To keep configuration you must boot 'Kodachi Persistent' or 'Kodachi Encrypted Persistence' (recommended), which require a persistent partition. Most USB writers (Rufus, UUI, YUMI) create that partition if you enable their persistence option, or create one with the dashboard/health-control persistence tooling.

Kodachi does not ship a built-in Remaster or ISO Creator tool, and there is no official one-click way to repack your customized installation back into a Live ISO. That is by design: Kodachi is assembled upstream from clean Debian using Debian live-build, driven from source recipes on the maintainer side, not captured from an already-installed running system.

What you want, capturing a configured system into a fresh non-persistent Live ISO, is a standard Linux remastering task, and mature community tools handle it. For a Debian-based system like Kodachi the best fit is Penguin's Eggs (penguins-eggs.net). Run it from your customized Kodachi system:

1. sudo eggs dad: one-time interactive build config.
2. sudo eggs produce: snapshots the running system into a bootable Live ISO.

The resulting ISO includes your extra apps, wallpaper, theme and shortcuts, and boots in normal non-persistent Live mode by default, so browser data, cookies, sessions, profiles and logins are discarded on every reboot. Other options are Linux Respin or Systemback (similar approach, less actively maintained); avoid Cubic, which only edits an existing ISO and does not capture your running setup.

Two cautions. First, clean your secrets before building: anything present at capture time is baked into the image, so clear browser profiles, accounts, shell history, SSH keys and saved credentials first; non-persistence only protects data created after boot, not what was already there. Second, the result is your own derivative image, not an official Kodachi release, so it does not carry my signed integrity hashes or the signed update/verification chain. If you want these apps in an official signed build, send me the request to evaluate for upstream inclusion instead of remastering on your side.

By design, Forensics Mode boots fully in RAM (toram) so you can analyze target machines without touching their disks, but it does NOT wipe memory on shutdown by default. Maximum Privacy is the mode geared toward automatic memory wiping. To get a RAM wipe under Forensics Mode, enable it explicitly via health-control or the dashboard.

Those top-tier profiles boot the entire system into RAM (toram) by design so they leave no disk traces, which makes them fast to use but heavy on memory; on low-RAM hardware they can exhaust memory. For lower RAM use and faster startup, boot the normal 'Kodachi Live' entry instead.

It can hurt plausibility. The default Randomize Timezone step deliberately mismatches IP geolocation and system clock, which is fine for pure anonymity but can flag sites that check timezone consistency. If you use a VPN with a known exit country, use the Sync Timezone button instead - it queries your public IP geolocation and sets a matching timezone, making your identity more plausible.

It is intentional, not a fault. LibreWolf uses DNS-over-HTTPS in TRR mode 3 (fail-closed), forcing all DNS through encrypted channels with no plaintext fallback so DNS cannot leak; it excludes localhost and kodachi.local so VPN/Tor routing still works. If a site fails to resolve, the encrypted-DNS path is failing closed by design rather than silently leaking - run Safe DNS Repair instead of disabling the protection.

The Rust conky-status telemetry gateway (legacy conky-details name) drives the Conky desktop telemetry display, which is a Desktop XFCE feature (the Terminal edition has no GUI/desktop to render it). The binary itself ships in the unified 28-binary pack at /opt/kodachi/dashboard/hooks/ on current Terminal ISOs, but its desktop telemetry display is only active on Desktop XFCE builds.

The KAICS binaries (ai-cmd, ai-gateway, ai-trainer, ai-learner, ai-admin, ai-discovery, ai-scheduler, ai-monitor) ship pre-installed in the unified binary pack, but the natural-language workflows depend on AI models and services that are enabled on demand rather than active out of the box on Terminal. The commands are documented for completeness; enable the KAICS add-on (models/services) for them to run.

Security4All is only the password for the default kodachi live account, set during build. Root login is disabled and does not use this password by design. Use the kodachi account (passwordless sudo via the sudo group) and run privileged commands with sudo rather than attempting a direct root login.

The session helper enforces a minimum hold duration of 500ms for emergency shortcuts; any configured value below that is rejected for safety so a brief accidental key combination cannot fire a destructive action. Set the hold duration to 500ms or higher (1500ms is the default).

No. Auto-login is intentionally DISABLED via a getty override during the build; the live session expects you to log in as the kodachi user (password Security4All) rather than dropping straight to a desktop. This is a deliberate hardening choice, not a misconfiguration.

This is a normal pattern, not a regression. Kodachi 8 shipped with far fewer features than Kodachi 9, so a smaller system naturally feels lighter. Every major version is also written from scratch rather than patched on top of the old one, which means a brand-new codebase cannot be as battle-hardened on its first release as a version that has had years of fixes. The exact same thing was said when v7 replaced v6, and again when v8 replaced v7: the older version always feels more stable at first because it is more mature, and then the new one catches up and overtakes it as it settles. Kodachi 9 carries a much larger surface (the full Kodachi dashboard, 25 documented Rust binaries, the AI stack, workflows, live scoring), so early 9.x builds trade some maturity for capability. Give the 9.x line the same time the older lines had and it becomes both faster and more stable than 8 ever was. Staying on 8 means staying on a smaller, no-longer-developed feature set that no longer receives fixes.

The Kodachi Dashboard is the central control application that orchestrates 600 generated commands across 25 Rust binaries with async execution so the GUI never freezes. On the Desktop edition it auto-launches at login and offers three switchable interfaces - the gamified Circle ring, the recommended Lite compact command center, and the Full professional multi-panel workstation - plus AutoShield, its guided first-boot setup wizard. It manages authentication, VPN/routing, Tor, DNS, identity randomization, hardening, monitoring and recovery, and presents an adaptive 0-100 security score across seven weighted categories.

You can run day-to-day privacy operations entirely from the Dashboard - all four modes share the same backend of 600 generated commands across 25 Rust binaries, and the Lite mode's Actions tab bundles authentication, DNS, Tor, identity randomization, power controls, connection, and the full network-recovery block. If you do not know which binary provides a feature, the Library tab indexes every command with descriptions, danger levels, and required authentication status. The terminal is available for scripting and advanced one-off commands (the same binaries like health-control and online-auth are CLI tools), but it is optional for normal use.

The Dashboard has three switchable interface modes - Circle (gamified 720x720 security ring, ~230MB RAM, beginner), Lite (recommended 1128x774 compact command center, ~230MB RAM, intermediate) and Full (professional multi-panel workstation, advanced) - and you switch between them from the Top Status Bar > Mode Selector at any time without relaunching, with your last choice remembered. AutoShield is offered as a fourth option in the first-boot welcome screen but it is a guided setup wizard route rather than a persistent interface mode (it is not part of the Circle/Lite/Full mode store). You can re-open AutoShield any time from the shield icon in the dashboard header.

On the Desktop edition it is the Kodachi Dashboard that auto-launches at login (via the ~/.config/autostart/kodachi-dashboard.desktop entry, which runs kodachi-dashboard-launcher), not AutoShield by itself. AutoShield is the Dashboard's first-boot wizard mode/route: on first run the Dashboard shows a welcome screen and offers AutoShield as a guided setup option alongside the Circle, Lite and Full modes. It is a countdown-driven hardening console covering identity randomization, secure routing, DNS setup and live verification, and you can re-open it any time from the shield icon in the dashboard header. It walks through 9 configurable steps with a countdown timer and a before/after identity comparison: 7 are enabled by default (Authenticate, Randomize Hostname, Randomize MAC, Randomize Timezone, Enable DNSCrypt, Connect WireGuard, Refresh Status) and 3 are disabled by default (Recover Internet, Harden PC Security, Torrify System + DNS), and when the countdown reaches zero it auto-executes the enabled ones. On the Terminal edition there is no GUI wizard at all - 'AutoShield' there is the login-shell information screen and interactive menu at /etc/profile.d/kodachi-autoshield.sh, run with the welcome or shield command.

Yes. AutoShield offers multiple countdown modes (60 seconds, 2 minutes, 5 minutes, 10 minutes, plus longer presets and a Manual no-auto-execute option). It has 9 configurable security steps; 7 are enabled by default (Authenticate, Randomize Hostname, Randomize MAC, Randomize Timezone, Enable DNSCrypt, Connect WireGuard, Refresh Status) and 3 are disabled by default (Recover Internet, Harden PC Security, Torrify System + DNS). Timer duration, step toggles, the auto-refresh interval and other preferences persist across reboots via the autoshield-settings.json file. Use a short timer for rapid hardening on boot, or Manual when you want to inspect every step first.

Yes. Under Settings > Dashboard > Window & Startup you can enable Auto-start on Boot to launch the dashboard automatically, Start Minimized to launch it hidden in the system tray, and toggle the Welcome Screen. There is also Close to Tray (minimize instead of exit), an independent show/hide tray-icon control, and an Always on Top option that pins the dashboard above all other windows.

Both are at-a-glance protection-status indicators that read the same live state as the dashboard. When you minimize or close the dashboard to the system tray, the tray icon shows three colored dots, read left to right: the left dot is Login (your online-authentication session is active), the middle dot is VPN (a VPN such as WireGuard is connected), and the right dot is Tor (the system is torrified / routing through Tor). Each dot is green when that layer is on/connected/active and red when it is off/disconnected/inactive - so all three green means you are logged in with both VPN and Tor engaged, while only the left green means you are authenticated but neither VPN nor Tor is active. The icon updates automatically as state changes, letting you monitor your posture without reopening the window. Left-click the tray icon to show or hide the dashboard, and right-click for the full quick-action menu. Hover tooltips do not render on Linux tray backends, which is exactly why the three dots exist as the indicator.

On the desktop, the Conky overlay carries a matching indicator: the small security-status square at the top-left of the Conky gauges panel. It is a grid of little blocks split into four quadrants - top-left is Authentication (logged in to Kodachi), top-right is VPN, bottom-left is Torrified (Tor routing), and bottom-right is DNS (DNSCrypt or Tor DNS). Each quadrant lights up cyan when that protection is active and stays dim/faded when it is off, so all four glowing cyan means authentication, VPN, Tor and encrypted DNS are all engaged, and any dim quadrant shows which layer is not yet active. It gives you a desktop-level status check without opening the dashboard. You can hide or screenshot-mask the Conky overlay from Settings > Dashboard > Conky Control.

Yes - the Kodachi Dashboard is locked behind a multi-layer authentication system: a strong password plus optional TOTP two-factor (compatible with any authenticator app), 8 single-use recovery codes, configurable auto-lock timeouts (1 minute up to 4 hours or never), and a full tamper-resistant audit log of every auth event. Separately, many privacy actions also require logging in to Kodachi cloud services (online-auth) to unlock premium features like VPN routing and the full identity-randomization step set; non-authenticated users in AutoShield can still run Authenticate, Refresh Status, Recover Internet, and Enable DNSCrypt. Repeated failed logins escalate through four configurable automated threat-response levels.

The Routing Guide is the dashboard's decision helper for choosing the right privacy path before you start switching protocols manually. It translates Kodachi's routing stack into plain-language tradeoffs - speed, account safety, censorship resistance, DNS privacy, and layered anonymity - so you can decide whether you need WireGuard, OpenVPN, anti-censorship transports, Tor, DNSCrypt, or a workflow-backed layered setup. For new users it makes the dashboard understandable without learning every binary first; for experienced operators it reduces mistakes like picking the wrong route for logged-in accounts or combining VPN and Tor in the wrong order.

Circle mode is a 720x720 interactive interface with 7 clickable security arcs - Authenticate, MAC Randomize, Hostname Spoof, Random Timezone, DNSCrypt, WireGuard VPN, and Torrify System - surrounding a central hub that shows your real-time IP, country flag, and a color-coded security score from 0 to 100. It celebrates milestones with victory animations at 25%, 50%, 75%, and 100% completion, dual auto-refresh (30s for IP/status, 60s for deep metrics), and 4 emergency controls (Routing Recover, Internet Recover, Restart Tor, Secure Shutdown). It is the beginner-friendly mode at roughly 230MB RAM.

Yes. The top status bar has a Compact Mode icon that hides the side panels to create a minimal workspace - useful on small screens or when you want the dashboard visible but out of the way. Click it again to restore the panels. It is a per-view toggle and is separate from the Circle/Lite/Full mode selector, which switches between full interface layouts rather than just hiding panels.

They are different things. Compact Mode is a quick top-bar toggle that simply hides the side panels in whatever mode you are in. Lite mode (officially the "Compact Command Center") is a full interface choice selected from the status-bar Mode Selector - a 1128x774px window with a 14-tab collapsible sidebar built for daily operations. You can use Compact Mode within Lite, Full, or Circle.

There are three primary modes plus AutoShield. Circle is a gamified 720x720px security ring with 7 clickable arcs (~230MB RAM, beginner). Lite is a 1128x774px compact command center with a 14-tab sidebar (~230MB RAM, intermediate, the recommended default). Full is an 1800x1000px professional workstation with 22 tabs across 4 major sections plus a drag-and-drop command queue (~380MB RAM, advanced). All three share the same backend of 600 generated commands across 25 Rust binaries.

Circle is for beginners who want quick guided security setup via an interactive ring. Lite is for intermediate users doing daily operations and is the recommended default. Full mode targets advanced/power users who need parallel and sequential command queuing, resizable panels, panel presets, and access to the complete 600 generated command surface. You can switch between them at any time from the status-bar Mode Selector without relaunching, and your last choice is remembered.

AutoShield is guided, beginner-friendly automation: the Kodachi Dashboard's first-boot wizard (Desktop edition) - a single screen with toggleable steps and a countdown timer that runs a preset hardening sequence. workflow-manager is the advanced engine: it chains arbitrary commands with success/fail conditions, regex and JSON-path evaluation, concurrent execution, timeouts and retries. Use AutoShield for fast one-screen setup; use workflow-manager when you need custom, conditional, repeatable multi-step automation.

Yes. The status indicator chips in the top bar (VPN, Tor, KNet, speed, etc.) are draggable. Drag them to reorder the bar to your preference, and the order persists across sessions so your most-used indicators stay front and center.

Yes. Switch to a lighter interface from the status-bar Mode Selector: Circle (gamified security ring, the easiest, aimed at beginners) or Lite (the recommended compact command center for everyday use). Both are far simpler than Full mode, and you can switch back at any time. For the full breakdown see the four dashboard modes and how to switch and which mode to use.

AutoShield has an auth gate. Non-authenticated users can only run Authenticate, Refresh Status, Recover Internet, and Enable DNSCrypt; identity randomization, routing actions, and premium features require successful Kodachi authentication first. Run the Authenticate step (or the top-bar Auth toggle) before the other steps will work.

Yes. Torrify System + DNS is intentionally off by default because it can conflict with WireGuard on first boot - the VPN must connect first and Tor be torrified separately afterward. Recover Internet is also off by default (not needed when the network is already up), and Harden PC Security is off because it applies system-wide kernel/service changes. The enabled defaults already give maximum shield strength on their own.

On the Terminal edition, AutoShield is the login-shell information screen and interactive menu installed at /etc/profile.d/kodachi-autoshield.sh, exposed as the welcome and shield commands. By default it does NOT auto-run on every login - the profile.d script exits early unless KODACHI_WELCOME_AUTO=1 or KODACHI_WELCOME_FORCE=1 is set; running welcome or shield invokes it on demand (those wrappers set the force flag). If your environment has enabled automatic startup, you can suppress it with 'export KODACHI_SKIP_WELCOME=1' (e.g. add it to ~/.bashrc), and on a non-persistent live session that change will not survive a reboot.

Open Settings > Dashboard > Performance and enable Performance mode, which disables glass blur, glow, and animations at once (glass blur is the most GPU-expensive). For a quick toggle use the clapperboard icon in the top status bar. Also disable Conky in Settings > Dashboard > Conky Control to free CPU.

RAM use depends on the dashboard interface: Circle and Lite are moderate (~230MB) and Full is heaviest (~380MB) because of its multi-tab workstation and command queue. The AutoShield first-boot wizard is the lightest surface (~180MB) but it is a guided setup route shown on first boot, not one of the persistent Circle/Lite/Full interface modes. Use Lite for daily operations and only switch to Full when you need the advanced service tabs, combining it with Performance mode and disabling Conky to lower overhead further.

It escalates through four configurable threat-response levels set in Settings > Security > Failed Attempt Protection. Level 1 Temporary Lockout auto-unlocks. Level 2 Block Until Recovery locks indefinitely until you use a recovery code. Level 3 System Shutdown immediately powers off (losing RAM data). Level 4 Trigger Panic runs the full irreversible panic sequence. Choose carefully - Levels 3 and 4 are destructive.

When TOTP is enabled the system generates single-use recovery codes; each works exactly once and they are also required to clear a Level 2 'Block Until Recovery' lockout. They must be stored offline beforehand (printed or in a separate encrypted volume) via Settings > Security > Credentials > Recovery Codes. If you did not save them, recovery requires system-level intervention.

Yes, for the current session or permanently. In the GUI open Settings > Dashboard > Conky Control: 'Enable Conky now' hides or restores the overlay immediately, and 'Start Conky on boot' controls whether it comes back after a reboot. The Lite dashboard diagnostics menu and the keyboard-driven Kodachi Rofi Actions menu (Display & Power) expose the same Conky Enable / Disable / Status controls. From the terminal the underlying commands are health-control conky-disable / health-control conky-enable for the session and health-control conky-boot-disable / health-control conky-boot-enable for boot persistence.

Yes. A screenshot privacy mask replaces sensitive Conky fields such as IP, MAC, country, city, hostname and session IDs with placeholders, then restores the real values when you turn it off. Toggle it from the Lite dashboard diagnostics menu or the Kodachi Rofi Actions menu via Conky Mask Enable / Conky Mask Disable / Conky Mask Status, or from the terminal with health-control conky-mask-enable, health-control conky-mask-disable and health-control conky-mask-status. Use it before sharing screenshots or screen recordings.

Yes - that is exactly what AutoShield is for. Open the AutoShield tab on the welcome screen (or the shield icon in the dashboard header), enable the controls you want, and Arm it. Examples include Connect VPN / Proxy (WireGuard or OpenVPN), Disable Bluetooth, Disable Wi-Fi, Disable Camera, randomize hostname and MAC, and sync the timezone. Pick a countdown and Arm it, and AutoShield runs your chosen actions automatically at dashboard startup so the same privacy posture is applied on every boot with no manual steps.

If clicking the icon does nothing and never shows a window, the dashboard binary is almost certainly failing to start because a system library it needs was removed. Run it from a terminal to see the real error: kodachi-dashboard. A message like error while loading shared libraries: libgstvideo-1.0.so.0: cannot open shared object file confirms it. The dashboard is a WebKitGTK application that depends on the GStreamer multimedia libraries; on an installed system these can get pulled out by apt autoremove after you uninstall another app, which silently breaks the dashboard while everything else keeps working.

Fix - reinstall and pin the libraries so they can never be removed again:

1. sudo apt update
2. sudo apt install --reinstall libgstreamer-plugins-base1.0-0 libwebkit2gtk-4.1-0 gstreamer1.0-plugins-base
3. sudo apt-mark manual libgstreamer-plugins-base1.0-0 libwebkit2gtk-4.1-0

The third command marks the libraries as manually installed so future apt autoremove runs leave them alone. Then launch the dashboard normally. If a different library is reported as missing, run ldd /opt/kodachi/dashboard/hooks/kodachi-dashboard | grep "not found" to list everything that is missing and reinstall those packages the same way. Fresh Kodachi builds pin these libraries by default, so this only affects systems where they were already removed.

The SOC (Security Operations Center) is a dedicated dashboard page that displays a live neural map of host-security telemetry. Open it via the Radar icon in the left navigation bar, immediately after System Health, in both the Advanced and Lite dashboards.

The view shows a central security score core surrounded by eight cluster hubs, VITALS, NETWORK, CONNECTIONS, PROCESSES, THREATS, AUTH, PRIVACY, and SYSTEM, each populated with color-coded nodes: green (ok), teal (info), yellow (warn), or red (critical). Hover any node to read its detail. Below the map, four additional panels provide a Score Breakdown, a Top Findings list (tagged with MITRE ATT&CK techniques where applicable), a Privacy Posture summary, and a Live Alert Feed. The toolbar lets you pause the display, adjust the refresh interval, filter by minimum severity, toggle individual clusters, and enable sound alerts for new critical findings.

The SOC is a read-only monitoring layer, it visualizes the same telemetry that Kodachi already collects and does not change system state. Use health-control or the dashboard action panels to act on anything the SOC surfaces.

KAICS (Kodachi AI Command Intelligence System) is a suite of local-first AI binaries that turn plain-English requests into real Kodachi and Linux commands. You type something like "am I leaking my IP" or "rotate my tor circuit" and it classifies your intent and runs the right tool. It also handles model training, learning from feedback, scheduling, system monitoring, and policy-enforced agent orchestration. The goal is to turn Kodachi from a manual toolkit into an intelligent, self-improving security assistant.

No. The AI is offline-first by design. The built-in TF-IDF classifier and the local ONNX semantic models run entirely on-device with no network calls, and local GGUF models (Mistral.rs) also run fully offline. You only reach the internet if you deliberately pick a provider-backed engine such as GenAI pointed at a remote provider, or Claude CLI. With the default and local engines, Kodachi AI works with no connectivity at all.

By default, no. All inference and policy evaluation run locally - TF-IDF, ONNX semantic matching, the ONNX intent classifier, and local GGUF models never leave your machine. The system only sends data off-device if you explicitly choose a provider-backed engine (for example GenAI configured against an external provider, or Claude CLI). Privacy-first local processing is the default behavior, and provider routing is always opt-in.

Kodachi exposes a tiered engine stack: TF-IDF statistical matching (built-in, zero setup), ONNX semantic embedding and an ONNX intent classifier, Mistral.rs running local GGUF models, GenAI/Ollama (local Ollama or a configured provider), a legacy local LLM path (deprecated, superseded by Mistral.rs), and Claude CLI. The system auto-routes across the local and provider tiers, falling back gracefully if a higher tier is not installed.

Run fully locally with no network: TF-IDF, ONNX semantic, ONNX intent classifier, and Mistral.rs (local GGUF). Network-capable: GenAI/Ollama is local if pointed at a local Ollama instance but reaches out if configured against a remote provider; Claude CLI always calls Anthropic's service. The default automatic routing only uses the local tiers plus the legacy local LLM - Claude CLI is never part of automatic fallback and must be selected explicitly.

It works immediately. ai-cmd ships with built-in TF-IDF and 350+ pre-configured intent patterns covering Kodachi services, Linux commands, SSL/TLS, network diagnostics, privacy checks, and hardware - no model download, no training, no configuration. Downloading the ONNX model and training is an optional one-time step that improves accuracy from roughly 60% (TF-IDF) to around 85-90% (semantic/classifier).

Yes. The Mistral.rs engine runs local GGUF models entirely on-device with streaming, tool calling, and broad model-architecture support. You download a GGUF model (for example via ai-trainer download-model --llm, with profiles like Qwen2.5-1.5B/3B or Phi-3.5-mini) and then run queries with --engine mistral. Nothing is sent off the machine when you use this path.

Yes, via the GenAI tier. Install Ollama, pull a model, and run ai-cmd query "..." --engine genai. When pointed at a local Ollama instance this stays fully local and privacy-safe; the same GenAI path can also target external providers if you configure it that way. It is opt-in - you must explicitly select the genai engine, it is not used by default.

The package includes only the essential ONNX models (about 152 MB) for the fast-path tiers - the custom Kodachi intent classifier, its tokenizer and label files, and the semantic embedding model. GGUF/LLM models for the higher reasoning tiers are not bundled, to keep the package light. You download them on demand with ai-trainer download-model, and the engine falls back gracefully to whatever tiers are present.

Only a CPU. No GPU, NPU, CUDA, or special hardware is required, and it runs identically on bare metal, in VMs, and in containers. TF-IDF-only needs about 128 MB RAM and 20 MB disk; ONNX plus Mistral.rs is comfortable around 512 MB RAM and ~250 MB disk; running the full stack with large GGUF models wants roughly 4 GB+ RAM and 3 GB+ disk. Any x86_64 CPU works at every tier.

Speed and accuracy scale with the tier. TF-IDF answers in under 1 ms at roughly 60% accuracy; the ONNX semantic/classifier models run in about 5-10 ms at 85-90%; local GGUF models (Mistral.rs) take a few hundred milliseconds with strong accuracy; Claude CLI is around a second at the highest accuracy. The fast-path ONNX intent classifier handles roughly 80% of queries in under 5 ms, routing only complex queries to slower reasoning engines.

Plain-English planning and preview (dry-run) work without elevated privileges. Live command execution through ai-cmd requires a valid online-auth state. sudo is only needed for specific privileged operations - for example training and learning steps (ai-trainer, ai-learner), the daemons (ai-monitor, ai-scheduler), and any underlying command that itself needs root. Day-to-day querying and preview do not need sudo.

The KAICS binaries (ai-cmd, ai-trainer, ai-learner, ai-admin, ai-discovery, ai-scheduler, ai-monitor, ai-gateway) ship pre-installed in the unified binary pack on both editions. The AI models and natural-language workflows are an optional add-on you enable on demand: on the Terminal edition you enable the KAICS workflows when needed, while Desktop has them wired into the dashboard out of the box.

ai-gateway is the machine-facing command API that AI agents and automation use instead of calling Kodachi binaries directly. It provides unified service discovery, machine invocation hints, deterministic JSON-argument execution, and - most importantly - a policy firewall that classifies every command by risk and blocks dangerous operations unless they are explicitly authorized. It is the safety net between AI agents and your system.

An approval ticket is a human-issued, time-limited authorization for a specific dangerous operation by a specific agent. An operator runs ai-gateway approve issue for, say, block-internet with a TTL (e.g. 600 seconds), and the agent must then present its verified identity plus that ticket to execute. Once the ticket expires the authorization is gone, so even a trusted agent cannot run destructive commands on its own without a fresh human approval.

The gateway recognizes a fixed set of verified agent IDs: anonymous, nullclaw, openclaw, picoclaw, nanoclaw, claude-code, gpt, gemini, and open-interpreter. Each agent has its own capability profile, and trusted batch mode requires a per-agent token.

ai-cmd is the human-facing natural-language CLI of KAICS. You ask in plain English ("is digi77.com ssl valid?", "who is on my network", "how private am I") and it classifies the intent and runs the matching Kodachi or Linux command. It supports preview/dry-run, interactive REPL mode, real-time streaming, native tool calling, and a feedback mechanism so you can correct misclassifications.

ai-cmd is the human-facing interface - you talk to it in natural language and it figures out and runs the command. ai-gateway is the machine-facing policy and execution layer that AI agents and automation use, with strict risk controls and JSON arguments. ai-cmd actually routes its live executions through ai-gateway for policy validation by default, though you can bypass that with --no-gateway for long-running commands.

ai-trainer manages machine-learning models - it downloads the ONNX semantic model, trains the intent classifier from command metadata, validates accuracy, snapshots, and exports models. ai-learner is the continuous-improvement engine: it processes accumulated user feedback and usage patterns to adjust the model so classification accuracy improves over time. All training and learning happen locally with no cloud dependency.

These are the three daemons. ai-discovery is a binary watcher and auto-indexer that detects new Kodachi binaries and makes their commands available to ai-cmd. ai-scheduler is a cron-based task scheduler for automating learning cycles, security checks, and maintenance. ai-monitor proactively watches system and security state (working with health-control, tor-switch, dns-leak) and raises suggestions when it detects issues.

ai-admin is the maintenance toolbox for the AI system. It manages the SQLite database that stores training data, feedback, predictions, and learning history, and provides diagnostics, integrity checks, backup and restore, performance tuning, index rebuilding, and cleanup. You use it for weekly maintenance and for recovery if the AI database is ever corrupted.

The binaries form a closed improvement loop. ai-discovery indexes available binaries; ai-trainer trains the model from that metadata; ai-cmd answers queries and collects feedback when it gets something wrong; ai-learner processes that feedback to adjust model weights; and ai-scheduler can automate the whole cycle on a schedule while ai-monitor feeds in system state. Each pass makes intent classification more accurate without sending anything to the cloud.

It is heavily guarded against that. Emergency intents (panic, block-internet, wipe) require elevated classifier confidence, and a cryptographically signed AI policy file sets per-category confidence thresholds and an approved-tool allowlist. On top of that, when execution goes through ai-gateway, destructive commands are blocked unless a human-issued approval ticket is supplied (see Does Kodachi classify AI-agent commands by risk and require human approval for dangerous ones?). Low-confidence or unknown queries route to slower analysis or human review rather than executing.

Yes. ai-gateway carries an embedded catalog of 800+ commands from 15+ Kodachi services and classifies every one into a three-tier risk model: Passive, Active, and Dangerous. Passive commands run freely, while Active and Dangerous commands are blocked unless a human-issued approval ticket is supplied via --approval-ticket. A policy firewall with allowlist enforcement, workspace path confinement, per-agent rate limiting, and a full audit trail back this up so an AI agent cannot quietly run destructive operations. Dry-run validation is always allowed, so an agent can plan first and only execute once the approval gate is met.

Kodachi ships with 11 auto-scored routing protocols through the routing-switch binary: WireGuard, OpenVPN, Tor, Xray-VLESS, Xray-VLESS-Reality, Hysteria2, Xray-Trojan, V2Ray, Shadowsocks, Mieru/Mita, and Dante (SOCKS5). Xray-VMess is also implemented but kept only as a legacy fallback (excluded from the security scoring table). They are pre-configured from your authentication card, so there is nothing to set up manually - run sudo routing-switch auto-select and it picks the best one.

No. Once you authenticate with online-auth, routing-switch automatically fetches your "card" containing all server details and configures every protocol for you. The documentation explicitly lists this as "Zero Configuration" - protocols are pre-configured from authentication cards. You just choose a protocol, or let auto-select choose the best-scoring one.

By Kodachi's own hardcoded scoring, WireGuard is the top choice on all three counts: it has the highest security score (98), highest reliability (98) and the highest speed score (95). So the common guess that OpenVPN is the most secure, Hysteria2 the fastest and WireGuard merely a middle option is not what the source says. Hysteria2 is the second-fastest (speed 94, just behind WireGuard) and is the best choice on unreliable/restrictive networks; OpenVPN is very reliable (97) but slower (~70-80% of line speed vs WireGuard's 90-95%). The honest takeaway: don't memorize a ranking - run sudo routing-switch auto-select, which weights speed 30%, reliability 25%, security 25%, plus measured latency and bandwidth, and picks the best overall protocol for your current network.

Yes. tor-switch can run multiple Tor instances with three native kernel-level load-balancing modes: Round-Robin (each new flow goes to the next instance in sequence via numgen inc mod N, so every new connection gets a different exit IP - good for general use and IP rotation), Weighted (traffic distributed by per-instance weights you assign, e.g. tor1 50%, tor2 30%, tor3 20% - good for prioritizing faster/more reliable instances), and Consistent Hashing (same source IP always maps to the same instance via jhash ip saddr mod N - good for banking, streaming and social-media sessions that block frequent IP changes). For application-level balancing it can also generate HAProxy configs with roundrobin or leastconn algorithms plus health checks and stats.

No. dns-switch ships with an extensive built-in database of hundreds of vetted DNS servers categorized by security level (reputable, normal/standard, encrypted, and emergency fallback). You can switch to a random secure server with sudo dns-switch random --type reputable, health-check servers with dns-switch test, or refresh the list from remote sources with sudo dns-switch fetch. You can also verify DNS behaviour with the online Kodachi DNS Leak Test at /tools/dns.html.

Yes, two forms. DNSCrypt is fully integrated - enable it with sudo dns-switch dnscrypt-set and DNS queries are encrypted to a resolver on 127.0.0.1, preventing your ISP or an on-path attacker from seeing the sites you visit. You can also layer DNSSEC signature validation (sudo dns-switch dnssec-on) and DoH (DNS-over-HTTPS, sudo dns-switch dot-on) on top. Separately, when the system is torrified, DNS is resolved through the Tor network (Tor DNS), so lookups inherit Tor's anonymity. The DNS category list also includes DNSCrypt and DoH servers for encrypted queries.

Yes, in two ways. (1) Microsocks SOCKS5 server: after connecting routing-switch to any protocol, run sudo routing-switch microsocks-enable -u USER -p PASS and other devices on your network point at socks5://USER:PASS@YOUR_IP:30050 (port auto-selected from 30050-30054). (2) QR-code mobile import: routing-switch showconfigqr wireguard (or shadowsocks/v2ray/xray variants) generates a QR you scan with the official WireGuard app, V2RayNG, Shadowrocket, etc. The Terminal Server edition is explicitly designed to act as a dedicated anonymized SOCKS gateway for an entire network.

Yes - and with routing-switch this is the only way to use the remote Tor route. Kodachi's remote Tor is VPN-only by design: connect any Kodachi protocol first - WireGuard, OpenVPN, or a proxy protocol (Shadowsocks/V2Ray/Xray/Hysteria2/Mita) - then sudo routing-switch connect tor layers Tor on that tunnel, keeping it as the underlay, no --force needed. A standalone connect tor with no tunnel is refused with an on-screen explanation, because the worker Tor SOCKS port is never exposed on a public IP: a publicly reachable Tor SOCKS port gets abused as an open proxy. The worker Tor binds only to the VPN networks, so it is reachable only after you join the Kodachi network. More broadly, tor-switch supports system-wide torrification on top of any existing VPN - WireGuard, OpenVPN, Hysteria2, Shadowsocks, V2Ray or Xray - via sudo tor-switch torrify-system-nftables-dns, and you can build multi-hop chains (e.g. triple VPN + Tor) with workflow-manager.

By design. Running sudo routing-switch connect tor with no tunnel active is refused, because Kodachi's worker Tor SOCKS proxy is never published on a public IP - a publicly reachable Tor SOCKS port is abused as an open proxy almost immediately. The worker Tor binds only to the Kodachi VPN networks, so to use it you first have to be inside the Kodachi network. connect tor layers Tor on top of any active Kodachi protocol - WireGuard, OpenVPN, or a proxy protocol (Shadowsocks, V2Ray, Xray, Hysteria2, Mita) - keeping that protocol as the underlay. Two supported ways: (1) connect any protocol first - e.g. sudo routing-switch connect wireguard (or openvpn, shadowsocks, hysteria2...) - then sudo routing-switch connect tor layers Tor on it; or (2) the easier route for WireGuard/OpenVPN - after connecting, point your browser's SOCKS5 proxy at 172.16.0.1:9050 (over OpenVPN) or 10.0.0.1:9050 (over WireGuard), with no connect tor step at all.

Yes. Rotate Tor exit nodes/IPs through tor-switch, switch routing protocols on demand with sudo routing-switch connect <protocol>, and on Desktop the dashboard has one-click Randomize MAC, Randomize Hostname and Randomize Timezone actions plus Tor exit-node country rotation. Verify the new identity with ip-fetch (full geolocation) or ip-fetch check-tor to confirm the Tor IP, and confirm DNS follows with dns-leak test.

Run routing-switch status (add --json for structured output) to see the active protocol and connection state, and routing-switch dns-info to see exactly which DNS/resolver endpoints the active route uses. ip-fetch shows the resulting public IP and geolocation, and ip-fetch check-tor confirms whether Tor is in the path. On Desktop, the dashboard and Conky overlay display the live routing/DNS state.

Yes. Beyond classic VPNs it ships censorship-resistant transports: Shadowsocks, V2Ray, the Xray family (VLESS, VLESS-Reality, Trojan), Hysteria2 (QUIC-based, good for unreliable/restricted networks) and Mieru/Mita. You can test which ones work in your environment with routing-switch test-protocol all and routing-switch benchmark, then connect to the best survivor (e.g. sudo routing-switch connect xray-vless-reality). Tor and HAProxy-balanced multi-instance Tor add further reach.

All of it. routing-switch provides system-wide protection - it routes ALL traffic, not just the browser, using native kernel routing for WireGuard/OpenVPN, redsocks transparent proxy for Tor, and a shared TUN interface (tun2socks) for the proxy protocols. tor-switch can also torrify the entire system at the firewall level (nftables/iptables) on top of any VPN.

Yes. Use tor-switch Consistent Hashing load-balancing mode (sudo tor-switch set-load-balancing-mode consistent-hashing): the same source IP always maps to the same Tor instance via jhash ip saddr mod N, so a given device keeps a stable exit IP per traffic type. The docs specifically recommend this mode for services that block frequent IP changes such as banking, financial services, streaming platforms and social-media sessions.

Yes. The Desktop dashboard includes a built-in VPNGate public-server browser under Essentials > Actions > Connection > VPNGate: it fetches and caches live public OpenVPN servers from the VPNGate API, lets you filter by country and sort by speed/ping/score/sessions, and connect in place or export .ovpn profiles. There is also a guided Fix Internet Wizard that pre-checks routing, DNS, DNSCrypt and torrify state before repairing connectivity.

Yes. routing-switch supports metric routing with private-network exclusion: sudo routing-switch connect wireguard --metric --dns-mode hybrid --exclude-private keeps LAN access (e.g. pinging 192.168.1.1 still works) while routing internet traffic through the VPN, and provides automatic failover if the VPN drops. Local/private ranges like 192.168.0.0/16, 10.0.0.0/8 and 172.16.0.0/12 are excluded from the proxy by default.

Yes. tor-switch supports multiple Tor instances, and you can create regional instances each pinned to a different exit country, then run them all simultaneously (sudo tor-switch start-all-instances) and verify with sudo tor-switch list-instances-with-ip. Combined with the load-balancing modes this lets you distribute traffic across several countries' exit nodes at once.

Yes. routing-switch can export configurations with routing-switch export-config [protocol], show the current config (showconfig), output it as a URL (showconfigurl), or as a scannable QR code (showconfigqr) for WireGuard, Shadowsocks, V2Ray and Xray variants. This lets you move a working profile to a phone or a third-party client without re-entering credentials.

Per the documented performance figures, WireGuard reaches about 90-95% of your line speed and OpenVPN about 70-80%, while Tor is typically only 1-10 Mbps because of its multiple relay hops. Connection setup is roughly 2-10 seconds depending on protocol, VPN protocols use ~40MB RAM and proxy protocols ~60MB. If Tor is too slow, multi-instance load balancing across several Tor instances improves throughput.

Yes, it is strongly discouraged. In a Tor -> VPN chain the Tor entry/guard node still sees your real IP, your ISP can still detect Tor usage, you lose access to .onion sites, performance is severely degraded, and trust shifts entirely to the VPN provider who can see your activity. Use VPN -> Tor instead: connect the VPN first, then torrify on top of it.

No, this is expected under load-balanced torrification. Kodachi runs multiple independent Tor instances in parallel, each with its own circuit and exit relay, usually in different countries, and nftables spreads outgoing TCP flows across them - so different apps legitimately leave through different Tor exits at once. This per-flow IP isolation is the point of multi-instance torrification and breaks 'one user = one exit IP' linkability. A direct external connection that is not to a local Tor port, however, is a genuine leak.

You are using a per-flow load-balancing mode (Round-Robin or Weighted) that varies the exit IP. Switch to Consistent-Hashing mode, where on a single workstation all apps share one source IP and hash to one instance, giving an effectively stable exit IP. Alternatively drop load balancing and use single-instance torrify for one stable IP and shared circuit.

It is a deliberate design choice: the generator uses two independent seeds (one for non-DNS TCP, one for DNS) so the two traffic classes distribute differently across the instance pool. Each is independently stable over time, so logged-in TCP sessions still see a stable exit. If you need TCP and DNS to share one exit, drop load balancing and use single-instance torrify.

No. The nftables/iptables torrification rules exclude localhost (127.0.0.0/8) from the TransPort redirect, so traffic FoxyProxy sends to a local Tor SOCKS port stays local and reaches Tor directly rather than being redirected through TransPort a second time. The result is a single Tor layer, not double routing.

This is expected, not a broken connection. Tor only carries TCP, so ICMP ping cannot traverse a torrified host and will always appear to fail even when HTTP/TCP connectivity is fine. The Fix Internet Wizard deliberately weights the HTTP connectivity check over the ping check when the host is torrified - trust the HTTP result.

Yes. The easiest path is the Mobile manager tab in the dashboard (see How do I use the Mobile manager tab?), which lets you copy share links, scan QR codes, and export configs for every active protocol in one place without any CLI. For CLI access, use routing-switch export-config wireguard (or shadowsocks, v2ray) to write the config to a file, or routing-switch showconfigqr wireguard to print a scannable QR code. Scan the WireGuard QR with the official WireGuard app on iOS/Android; for Shadowsocks, V2Ray and Xray variants use a V2RayNG/Shadowrocket-class client. Run routing-switch export-config with no protocol to export all of them at once. None of these export/show commands need sudo.

Each protocol row in the Mobile manager tab shows an "Open in" app strip where every recommended client appears once with its own iOS and Android store links, plus a tooltip; that in-app list is always authoritative. The canonical picks per protocol:

• WireGuard, iOS: WireGuard (official), Hiddify, Streisand, Shadowrocket ($2.99). Android: WireGuard (official), Hiddify, NekoBox. (Happ does NOT support WireGuard.)
• OpenVPN, iOS: OpenVPN Connect. Android: OpenVPN Connect, OpenVPN for Android (open-source). No QR (config too large), use Export and import the .ovpn file.
• Shadowsocks, iOS: Shadowrocket ($2.99), Outline, RocketTunnel (free, incl. SS2022), Streisand, V2Box, Happ, Hiddify. Android: V2RayNG (GitHub), Outline, RocketTunnel (free, incl. SS2022), Hiddify, V2Box, NekoBox, Happ.
• V2Ray (VMess), iOS: Shadowrocket, V2Box, Streisand, Happ, Hiddify. Android: V2RayNG (GitHub), V2Box, Hiddify, NekoBox, Happ.
• Xray (VLESS / VLESS-Reality / Trojan / VMess), iOS: Happ, V2Box, Streisand, Hiddify, Shadowrocket. Android: V2RayNG (GitHub), V2Box, Hiddify, NekoBox, Happ. (Each Xray variant is its own row using the same clients; the plain VLESS-TLS row also lists RocketTunnel, which imports plain VLESS but not Reality / Trojan / VMess.)
• Hysteria2, iOS: Happ, Hiddify, Streisand, V2Box, Shadowrocket. Android: Hiddify, NekoBox, V2RayNG (GitHub), Happ, V2Box.
• Mita (Mieru), iOS: Shadowrocket ($2.99, mieru added 2026). Android: NekoBox + mieru plugin, or Hiddify. (Happ / Streisand / V2Box do not support mieru.)
• Dante (SOCKS5), iOS: Shadowrocket, Happ, Streisand, V2Box. Android: NekoBox, V2Box, Hiddify, or the native system SOCKS proxy settings.
• Tor, iOS: Onion Browser. Android: Orbot. Point any app with a SOCKS field at the printed host:port.
• Private DNS, no app needed: paste the host:port into iOS Settings > DNS or Android Settings > Private DNS (Android 9+), or use Intra on Android.

Universal multi-protocol clients (Hiddify, Happ, NekoBox) cover most protocols at once, so if you already have one installed you usually do not need a per-protocol app.

Sign in first: the tab is locked until you authenticate. Each active protocol row then offers four actions: Copy share link (copies the URI such as vmess://… or wg://… to your clipboard), QR (shows a scannable QR code in a modal), Export (writes the config file to disk), and Config (displays the raw config text inline). A tooltip on each row suggests the recommended mobile app for that protocol. Four bulk actions at the top let you open all QR codes in a gallery, export all configs at once, save all QRs as PNGs, or copy all share links in one click. An external-provider section covers Riseup and VPNGate bulk exports with the same actions, and a raw authentication card viewer at the bottom shows the full card JSON for manual imports. Available in the Welcome screen and in both the Lite and Advanced dashboards.

Run routing-switch showconfigurl to print the current protocol's configuration as a URL, or routing-switch showconfigqr to render it as a QR code in the terminal; add a protocol name (for example routing-switch showconfigqr shadowsocks) to target a specific one. Use routing-switch showconfig to just display the configuration. All four of these are read-only and do not require sudo. QR works with WireGuard, Shadowsocks, V2Ray and the Xray variants (xray-vless, xray-vless-reality, xray-trojan).

Yes. routing-switch has built-in VPNGate integration providing 100+ public VPN servers that require no account or authentication, so you can route traffic even without your own VPN subscription. It can also export those servers with routing-switch vpngate-export / vpngate-export-all, which are read-only and do not require sudo. Combined with automatic protocol scoring and selection, this gives you a working tunnel out of the box.

Yes. The External VPN Providers tab (Globe icon on the dashboard sidebar) catalogs 13 third-party providers: VPN Gate, Riseup, NordVPN, IVPN, PIA, Surfshark, AirVPN, Mullvad (WireGuard-only since 2026), Windscribe, ProtonVPN, ExpressVPN, TorGuard, plus a "custom" pseudo-provider for pasted configs. Free anonymous pools (VPN Gate, Riseup) connect with no account. Paid providers store credentials at ~/.config/kodachi/vpn-credentials.json mode 0600. Set them once via the per-provider editor, then click any server row to connect. ProtonVPN / ExpressVPN / TorGuard have no public auto-fetch API; their cards link to the provider site so you can download the .ovpn and paste via Import config.

Yes. The Import config widget at the top of the External VPN Providers tab auto-detects the protocol from any pasted body. It handles OpenVPN .ovpn, WireGuard .conf, Shadowsocks JSON, V2Ray JSON, Hysteria2 YAML, and the URI schemes vmess://, vless://, trojan://, ss://, hysteria2://, tuic://. It also recognizes Clash YAML (proxies: list) and sing-box JSON (outbounds: list) subscriptions: a single paste explodes into N profiles. The Validate button does a dry-run preview (CV-3 draft-validate) so you see the detected protocol, endpoint, and any warnings before committing.

Two ways. Without measuring: connect-fastest sorts by provider-reported speed_bps and load, which works well for VPN Gate and AirVPN (which publish those metrics) but less so for others. To use real measured latency, click the Test latency chip in the action bar (or run routing-switch providers benchmark <id> --top 20). This pings each cached server (ICMP first, TCP-connect fallback) with bounded concurrency and stores latency_ms in the cache. Manual only (never auto-runs), same UX as ip-fetch's manual cache refresh. After a benchmark, connect-fastest prefers measured latency over provider-reported speed.

Yes - but through NetworkManager configuration, not a boot-time MAC-change script. There is no systemd service, live hook, or rc.local that runs macchanger or health-control to change the MAC at startup; those tools are on-demand only (dashboard/menu triggered). The randomization comes from /etc/NetworkManager/conf.d/99-kodachi-mac-randomization.conf: Wi-Fi scans use a random MAC, each Wi-Fi connection uses a per-boot pseudo-random (stable) MAC, and Ethernet gets a fresh random MAC per connection. So the address seen on the network is randomized every boot rather than your burned-in hardware MAC. This applies to NetworkManager-managed Ethernet/Wi-Fi (the normal case); an interface not managed by NetworkManager, or a tool that bypasses it, would still expose the real MAC.

Kodachi randomizes the MAC for privacy via NetworkManager (wifi.cloned-mac-address=stable), so a router that only hands out IPs to provisioned/whitelisted MACs rejects the randomized one. Resetting the MAC by hand does not hold because NetworkManager re-applies the cloned MAC on every connect. The fix is to make that one connection use the real hardware MAC: in the connection settings set Cloned MAC Address = Permanent, or from a terminal run sudo nmcli connection modify "YOUR_SSID" 802-11-wireless.cloned-mac-address permanent then sudo nmcli connection up "YOUR_SSID". Only that network loses randomization; every other network stays private (see how the MAC is randomized at boot). On a live USB this is not saved - reapply each boot or install to disk, where it persists.

Kodachi locks /etc/resolv.conf immutable for DNS-leak protection, which stops third-party VPN clients from writing their tunnel DNS - so Mullvad/ProtonVPN fail to set DNS and their own kill-switch blocks all traffic. Hand DNS over to the VPN client first, then connect.

From the command line:

1. sudo dns-switch external-dns --state on: unlocks resolv.conf and pauses Kodachi DNS protection. This is an emergency command, so it needs no online authentication (important when a failing VPN has already cut your internet).
2. Connect your VPN in its app (or mullvad connect); it now sets its DNS and stays connected.
3. When finished: disconnect the VPN, then sudo dns-switch external-dns --state off to restore Kodachi-managed, re-locked DNS. Check the current state anytime with dns-switch external-dns --state status (no sudo).

From the Dashboard: open the Full dashboard → Essentials → DNS (Advanced tab of the DNS command builder), select External VPN DNS, set the state to on before connecting your VPN and back to off when you are done.

Notes: while it is ON, Kodachi's immutable DNS-leak lock is paused, so your VPN client must enforce its own leak protection (Mullvad and ProtonVPN both do). The setting persists across reboots on an installed system; re-run it each boot on the live ISO. Pi-hole cannot be enabled while External VPN DNS is ON because both need to own system DNS. If a VPN client strictly requires systemd-resolved rather than writing resolv.conf, switch DNS mode with sudo dns-switch set-mode --mode modern.

No, this is normal and expected behavior, not a bug or a leak. The Kodachi Network indicator (also shown as Kodachi Cloud / KNet in the status bar) only checks whether your current public IP is recognized as part of Kodachi's own VPN infrastructure: the dashboard asks the kodachi.cloud service whether your exit IP belongs to a Kodachi node. When you connect a separate VPN such as PIA, your traffic now exits through that provider's server, so your public IP becomes a PIA IP rather than a Kodachi node IP. The check correctly returns false and the indicator goes inactive.

Only one VPN exit can be active at a time, so being connected to PIA and being shown as off the Kodachi network at the same moment is the correct result. To make the indicator active again, disconnect the third-party VPN and route through Kodachi's own VPN/nodes instead. If your third-party VPN client itself refuses to connect or reports "internet blocked", see how to use a third-party VPN GUI like Mullvad or ProtonVPN.

Torrify routes your whole system through Tor on top of your active VPN connection. It works over most Kodachi protocols, but bare system torrify does not work over xray-vless-reality (XTLS Vision) by default. This is a known, by-design limitation of the XTLS Vision flow, not a Kodachi bug.

Root cause. The Reality protocol uses XTLS Vision (flow: xtls-rprx-vision). Vision is designed to detect the TLS handshake inside the tunnel, pad it, and then splice the raw stream directly, bypassing an extra TLS wrapper. Tor relay connections are themselves TLS, so when your system is torrified over Reality, Vision sees Tor's nested TLS handshake as an anomaly, mangles the stream, and Tor gets stuck at roughly 10% bootstrap with unexpected eof while reading / TLS_ERROR on every relay. The Xray-core project closed the relevant issue (#3206) as "not planned" because the behavior is intentional: Vision is built to splice exactly one TLS layer and a second nested TLS layer breaks that assumption.

How it was confirmed. All tests used the same exit server (198.105.112.55). Through that server, switching to xray-vmess (no Vision flow) or WireGuard made Tor bootstrap to 100% and exit through a real Tor IP. Only xray-vless-reality failed. The failure is Vision-specific, not server-specific.

Fix 1: use an obfs4 bridge (works today, verified). obfs4 wraps Tor's traffic in obfuscated, non-TLS bytes. Vision's TLS-in-TLS detection never triggers because there is no TLS handshake for it to find. With an obfs4 bridge configured in Tor Browser, Tor bootstrapped to 100% over a Reality VPN connection and exited through a real Tor node. Configure Tor Browser to use obfs4 bridges (Settings > Connection > Use a bridge > obfs4) and use it on top of your Reality connection. Kodachi is adding bridge support to the system-wide tor-switch torrify command so the full system can torrify over Reality via bridges without needing Tor Browser specifically.

Fix 2: switch to a non-Vision protocol for Tor (no bridges needed). WireGuard and OpenVPN use native kernel routing with no TLS splicing involved, so plain system torrify works over both. xray-vmess, Shadowsocks, V2Ray, Hysteria2, and Mita/Mieru also carry no Vision flow, so torrify works over them as well.

Protocol compatibility table.

The underlying reason is XTLS Vision's TLS-in-TLS handling. There is no server-side or client-side configuration that makes plain (non-bridged) Tor survive through a Vision-enabled Xray path. You must either drop Vision (switch protocol) or use an obfs4 bridge.

It is a 0-100 score computed by sudo health-control security-score that aggregates 7 weighted categories: System Security (30 pts), Privacy & Anonymity (25 pts), Network Security (20 pts), Authentication (10 pts), Device Security (5 pts), Advanced Privacy (5 pts), and Data Protection (5 pts). The result maps to five tiers: Excellent (90+), Good (75-89), Fair (60-74), Partial (40-59), and Critical (under 40).

Each category contains individual weighted checks. The denominator is adaptive: checks that physically cannot apply on your system are excluded rather than counted as failures - for example a live ISO drops disk encryption, swap encryption, auto-updates, encrypted containers, and backup encryption; a BIOS-only machine drops Secure Boot; a headless system drops Bluetooth/webcam. That is why the total may read e.g. 57/82 instead of 57/100. The score is a percentage of applicable points, so both a live ISO and an installed system can still reach 100%.

Privacy & Anonymity is worth 25 points: Tor + system torrification (8 pts), DNS privacy via DNSCrypt/DoH/DoT/DNSSEC (7 pts), an active VPN or proxy (6 pts), privacy-focused browser configuration (2.5 pts), and MAC randomization (1.5 pts). VPN/proxy and Tor are scored independently, so running both layers them additively rather than one replacing the other.

System Security is the largest category at 30 points: LUKS full-disk encryption (8 pts), an active firewall (8 pts), encrypted swap (4 pts), auto security updates (4 pts), UEFI Secure Boot (3 pts), kernel hardening (2 pts), and AppArmor/SELinux (1 pt). On a live ISO the encryption, swap-encryption, and auto-update checks drop out of the maximum because they cannot apply.

Enable more applicable protections. The biggest practical levers are: connect a VPN/WireGuard, enable DNSCrypt, torrify the system through Tor, and (on installed systems) install with LUKS full-disk encryption and keep auto-updates on. Run sudo health-control security-harden to apply hardening, and use security-remediate to fix flagged weaknesses and security-verify to confirm the state. The score only rises when you enable protections that actually apply to your hardware and session.

Kodachi has 7 independently enableable hardening modules plus preset profiles. Standard is balanced, network-safe hardening (kernel, network, memory) suitable for daily use. Paranoid applies all 7 modules at maximum - network isolation, sandboxed processes, aggressive filesystem restrictions - for high-threat scenarios, but it may break browsers, internet access, and some applications. Break-Monitoring adds active breach detection with file integrity tripwires and anomaly alerting. Apply hardening via sudo health-control security-harden; only push toward 90+ if you genuinely need it, since aggressive hardening sacrifices convenience.

Not necessarily. A score of 50-65 with VPN + DNSCrypt + firewall active is already far more secure than the vast majority of operating systems. Pushing to 90+ stacks aggressive features (Secure Boot + LUKS + full hardening + Tor) that can cause service breakage, hardware-detection issues, and longer boot times. Only target 90+ when you are protecting something truly critical and accept that convenience will suffer.

Because the denominator is adaptive. On a live ISO, disk encryption, swap encryption, auto-updates, encrypted containers, and backup encryption are marked N/A and drop out of the maximum - a fully hardened live session still reaches 100%, and an installed system hardened to the same level reaches the same ceiling, so the two can score identically. On an installed system those checks become active; an installed system without LUKS scores lower than the same-effort live session because the disk-encryption check is now applicable and failing. Kodachi does not penalize USB-boot users and does not reward installation by itself - only enabling more applicable protections raises the score.

No. Checks that cannot physically apply to your system (disk encryption on a live ISO, Secure Boot on a BIOS-only machine, Bluetooth/webcam on a headless box, WiFi on a wired-only host) are excluded from the maximum, not scored as zero. They drop out of the denominator entirely, so an inapplicable check can never count as a failure against you.

Yes, two independent paths exist. (1) Boot-time LUKS nuke: when you install with full-disk encryption using the Debian text installer entry "Install Kodachi (Text + Full Disk Encryption, Boot-Nuke Compatible)", a cryptsetup-nuke-password is configured - entering that special passphrase at the boot LUKS prompt instantly destroys the encryption headers, rendering the drive unreadable. (2) Dashboard/CLI duress path: health-control has a four-tier panic escalation - Soft (kill network, lock screen, wipe clipboard), Medium (+kill processes, clear RAM, unmount volumes), Hard (+sdmem RAM wipe and immediate shutdown), and Destroy (+LUKS header wipe, drive unusable). The difference: the boot nuke triggers from the encryption passphrase prompt before login and needs the boot-nuke-compatible install layout; the panic path runs from a logged-in session and escalates through reversible-to-irreversible levels. See also the full step-by-step destruction paths and which panic tiers are recoverable.

The boot-time nuke works at the initramfs LUKS passphrase prompt - entering the special nuke password destroys the disk encryption headers before anyone logs in, which is ideal for a coerced unlock at a border or seizure. It requires installing via the Debian text installer "Boot-Nuke Compatible" encrypted entry so /boot stays outside LUKS (the Calamares GUI encrypted install can place the first LUKS prompt in GRUB, which blocks duress-at-boot nuke). The dashboard/CLI panic path (health-control panic-soft/medium/hard plus the Destroy tier) runs from a live session and can stop at reversible levels (network kill, screen lock) or escalate to RAM wipe, forced shutdown and LUKS header destruction. See also the full step-by-step destruction paths.

Kodachi provides three independent destruction paths, each suited to a different scenario.

1. Destroy Kodachi sidebar icon. A red Destroy Kodachi icon (skull) is the last icon at the bottom of the dashboard's left sidebar, present in Full, Lite, and Circle dashboards. It can be shown or hidden from Settings › Security. Clicking it opens an in-window confirmation dialog (style is configurable in Settings: type DESTROY (default), a Yes/No prompt, or immediate with no confirmation), then runs a combined, two-stage sequence: first it permanently wipes every active LUKS encryption header (instantly unrecoverable), then it runs the full dashboard panic-hard, kills the network, wipes RAM and clipboard, shreds sensitive files, destroys the boot record / MBR / EFI, and forces a power-off. No fake update screen is shown; this path is intended for direct physical access to the machine. It is irreversible once triggered.

2. Emergency global keyboard shortcuts (session helper). The kodachi-session-helper daemon registers session-wide hotkeys that work anywhere in the X11/XFCE session, even when the dashboard window is closed. Hold 3+ modifier keys plus a trigger key for ~1500 ms (configurable, minimum 500 ms; auto-repeat is rejected and synthetic input cannot activate them). Configure the key combinations in Settings > Password Security (or Settings > Emergency Shortcuts). These shortcuts can trigger soft/medium/hard panic as well as the full destroy sequence without needing to open the dashboard. X11 session required, Wayland is detected and fails closed.

3. LUKS Nuke (Power/Essentials section + boot-time). From the dashboard's Power or Essentials section, the LUKS Nuke control lets you immediately destroy the header of a selected encrypted device ("Execute Nuke"), making it permanently unreadable. Separately, if you installed using the Debian text installer entry "Install Kodachi (Text + Full Disk Encryption, Boot-Nuke Compatible)", you can configure a special boot-time nuke password via Dashboard > Emergency > LUKS Nuke: entering that password at the initramfs LUKS prompt at boot triggers instant header destruction before login, ideal for coerced-unlock scenarios at a border or seizure. A fourth path also exists at boot: the duress password entered at the dashboard login screen shows a convincing fake "System Update" screen while destruction runs silently behind it.

All destruction actions are irreversible. If you need a recoverable emergency response, use Panic Soft (kills network, wipes clipboard, locks screen) or Panic Medium from health-control instead. See also boot-time LUKS nuke vs dashboard panic and which panic tiers are recoverable.

Yes. Locally, ip-fetch check-tor confirms whether your traffic exits via Tor, and dns-leak test (or routing-switch dns-info) confirms DNS is not leaking to your ISP. Online, Kodachi hosts public verification tools: Verify Anonymity at /, the DeepTrace IP report at /tools/ip.html, the DNS Leak Test at /tools/dns.html, and a Browser Fingerprints test at /tools/user-finger-prints.html.

It can be, when you enable it. health-control includes a RAM wipe system that integrates with systemd shutdown hooks - when enabled (sudo health-control ram-wipe-enable), RAM is scrubbed (via sdmem / kodachi-wiper) before power-off completes, defending against cold-boot attacks that freeze RAM to extract keys. It is not forced by default; you turn it on, and the higher panic tiers (Hard/Destroy) also perform a RAM wipe as part of emergency shutdown.

Yes. health-control offers granular secure-deletion: wipe-file (custom pass count), wipe-directory, wipe-batch, wipe-logs (system/all), wipe-browser-data (per browser or all), wipe-free-space, wipe-pattern (e.g. *.tmp), plus scheduled wiping (wipe-schedule temp --frequency daily) and wipe-verify to confirm a file was destroyed. These let you scrub targeted data without destroying the whole disk. Pass count is configurable (for example wipe-file --passes 7), and all wipe operations require sudo and are irreversible.

Yes. integrity-check verifies file signatures and hashes so you can confirm binaries have not been tampered with, and health-control provides a security score across system hardening, privacy configuration, network protection and authentication status. health-control also includes hardware/USB device protection and net-check diagnostics, so you can continuously confirm the system is in a known-good state.

Yes. The RAM wipe engine integrates with systemd shutdown hooks so memory is scrubbed before power-off, specifically to defend against cold-boot attacks where an adversary freezes RAM chips to extract encryption keys. You can choose the wipe engine, test it (sudo health-control wipe-ram-test), and the installer can enable the init_on_free=1 kernel parameter for additional memory hygiene.

Yes. The Lite Dashboard diagnostics menu includes Conky Mask Enable / Disable / Status, which mask sensitive fields such as IP, MAC and country data in the Conky panels so you can screenshot safely, then restore the real values when you unmask. You can also fully hide the Conky overlay from Settings > Dashboard > Conky Control.

No. Tirdad ships as an unsigned out-of-tree DKMS module, and Secure Boot makes the kernel enforce module signatures (module.sig_enforce), so the kernel refuses to load Tirdad by design. To use it, disable Secure Boot in firmware, or reboot into a boot entry that has neither module.sig_enforce nor kernel lockdown - Kodachi Live, Persistent, Encrypted Persistence, CPU Hardened, Forensics, or DMA Protection all run Tirdad.

This is correct, intentional behavior, not a bug. The kernel blocks loading any unsigned module when lockdown is active or module.sig_enforce=1 is set, and Tirdad is unsigned. In the Kodachi boot menu, Secure Boot Mode and Full Hardening set module.sig_enforce=1, and Maximum Privacy and Full Hardening set lockdown=integrity - any of these blocks Tirdad. Forensics Mode does NOT block it (no lockdown, no sig_enforce). Current ISOs report the truth and the score marks Tirdad N/A instead of penalizing you; reboot into Live, Persistent, Encrypted Persistence, CPU Hardened, Forensics, or DMA Protection to actually run it.

There are two prerequisites. First, you need an actual LUKS-encrypted partition: the nuke password destroys LUKS keys, so you must have booted Encrypted Persistence or installed with full-disk encryption - a plain live or unencrypted-persistent session has no LUKS device to attach a nuke key to. It also needs the health-control binary and the cryptsetup-nuke-password package (pre-installed in the ISO); if 'health-control luks-detect' finds no LUKS device, there is nothing to configure. Second, the LUKS unlock prompt must stay in initramfs: if you used the Calamares GUI encrypted install the first prompt may land in GRUB instead, which blocks duress-at-boot nuke, so the dashboard fail-closes and refuses to configure it - reinstall from the GRUB Debian-installer entry 'Install Kodachi (Text + Full Disk Encryption, Boot-Nuke Compatible)', which keeps /boot outside LUKS. The manual 'Execute Nuke' for the selected device still works as an emergency action even when boot-time nuke is blocked.

The raw 'cryptsetup luksAddNuke /dev/sdX' command does not create any LUKS header backup - that is a known limitation of the manual method. Use 'sudo health-control luks-nuke --action configure' instead, which adds an automatic GPG-encrypted timestamped header backup, LUKS validation, package auto-install, and audit logging.

That is the intended fail-closed behavior, not a malfunction. Entering the nuke password instead of the normal LUKS password instantly overwrites the LUKS header and wipes every key slot, so the boot fails (expected) and the data is permanently unrecoverable. The only recovery path is the GPG-encrypted LUKS header backup automatically created before nuke configuration (saved under the hooks backups directory), intended for authorized recovery only.

Yes, you can layer them, but order is critical: connect the VPN first, then torrify the system. If you torrify first and then connect the VPN, the VPN rewrites the routing table and breaks the Tor circuits. In AutoShield, let it connect WireGuard (or another protocol) first, then run 'Torrify System + DNS'. See also Can I layer Tor on top of a VPN for double protection?

The kodachi-session-helper daemon that provides them requires an X11/XFCE session; Wayland is detected (XDG_SESSION_TYPE/WAYLAND_DISPLAY) and the helper fails closed, so the shortcuts do nothing under Wayland. Use an X11/XFCE session and configure them in Settings > Emergency Shortcuts. They also require holding 3+ modifier keys plus a trigger key for about 1500ms by default - a quick tap or auto-repeat is rejected by design.

Emergency shortcuts use hold-to-trigger: you must physically hold 3+ modifier keys plus the trigger key for the configured duration (1500ms default, minimum 500ms enforced), and auto-repeat is rejected, to prevent accidental activation. X11 key grabs are also corroborated against raw /dev/input events so synthetic input cannot trigger them. Hold the full combination physically and long enough.

Panic Soft is fully recoverable: it blocks internet, stops Tor, clears DNS, and randomizes MAC/hostname with no data loss; run recover-internet to restore connectivity. Panic Medium is partially reversible: network recovers, but killed processes, wiped browser data, SSH/GPG keys, messaging data, logs, and RAM are gone permanently. Panic Hard is IRREVERSIBLE: it additionally wipes RAM, unmounts devices, and then immediately shuts the system down.

Run 'sudo health-control recover-internet', which automatically runs through a multi-method recovery sequence (flush nftables/iptables, reset firewall, bring up interfaces, restart NetworkManager/systemd-networkd, flush DNS, restore resolv.conf, renew DHCP), falling through each until connectivity returns. There is also a lighter 'fast-recover-internet' that tries a quick fix first. From the GUI use Essentials > Actions > Network Recovery > Fix Internet Wizard.

No. Unlike Maximum Privacy, Forensics, and Full Hardening (which all set ipv6.disable=1), the 'Kodachi Secure Boot Mode' entry does not disable the IPv6 stack - it focuses on module.sig_enforce=1 and lockdown=confidentiality. So if you need both Secure Boot enforcement and a runtime-toggleable IPv6 stack, use Secure Boot Mode rather than the other top-tier entries.

Yes. online-info-switch freshness generates a proof-of-freshness report that combines the current UTC and local time, your live IP and country, fresh security-news headlines, the current Bitcoin block height, and live cryptocurrency prices. Because the Bitcoin block height and news headlines change constantly and cannot be predicted in advance, the bundle demonstrates the snapshot was produced at that moment rather than replayed from an old recording. You can emit it as --json or --json-pretty for automation, and it does not require sudo.

Yes. integrity-check maintains baseline checksums for critical system files and binaries using BLAKE3 hashing (with SHA-256 as a fallback) and also performs cryptographic signature verification, so both unauthorized file modification and unsigned/forged binaries are detected. It supports scheduled and on-demand scans, configuration-file monitoring, custom file lists and exclusion patterns, and an offline mode. This is what backs Kodachi's binary authentication and tamper detection.

Yes. permission-guard is built specifically to monitor file ownership and permissions and automatically correct insecure ones, including root-owned files that end up in user directories after privileged operations. It does real-time monitoring across configurable watch directories with pattern-based exclusions, can run as a background daemon, and outputs JSON or text. This is also why you stop permission-guard before a binary update, so it does not revert ownership mid-update.

Yes. workflow-manager uses a hybrid conditional system that combines success/fail states with regex and substring pattern matching and JSON-path evaluation (dot fields plus array indexes), so a step can branch on a specific value inside a previous command's JSON response. It also supports prerequisites validation, system-state probes, retry logic, concurrent execution within a workflow, interactive pause checkpoints, dry-run mode, and JSONL telemetry logging. It ships with 96+ ready-to-use built-in profiles, and you can add your own.

Yes. Kodachi follows a zero-trust, authentication-first design and uses TLS 1.3 with pinned certificates for network operations across its services. Certificate pinning means a service rejects a connection even if it presents an otherwise valid certificate that is not the expected pinned one, which defeats man-in-the-middle interception that relies on a rogue or compromised certificate authority.

Your hardware information stays private. To recognize a machine, Kodachi builds a privacy-preserving fingerprint by running stable system characteristics through SHA-256, a one-way hash. Only the resulting hash is ever used, and the underlying device details stay on your computer and are never transmitted.

A one-way hash cannot be turned back into the original values, so this fingerprint lets Kodachi recognize a returning machine and keep abusers out while keeping your hardware details private. Authentication also asks for no email and no phone number (see is authentication tracking me), so the service works without ever needing to know who you are.

By design. LibreWolf runs under a strict AppArmor profile so that if the browser is ever exploited or hijacked it cannot read the rest of your home directory - your documents, pictures, dotfiles, keys and other sensitive files stay out of reach. The profile deliberately exposes only ~/Desktop and ~/Downloads (recursively) for opening uploads and saving downloads; everything else under $HOME is sealed off. This is a containment feature, not a bug - keep any file you want to open or save in the browser inside the Desktop or Downloads folder.

Yes. Kodachi Desktop uses the XFCE screensaver (xfce4-screensaver) for the idle lock, and you control both the timeout and whether it locks at all.

To increase the timeout (keep the password lock): open Settings → Screensaver and raise Blank after, then on the Lock Screen tab raise the delay before the password is required. From a terminal as your desktop user the same settings are, in minutes: xfconf-query -c xfce4-screensaver -p /saver/idle-activation/delay -n -t int -s 60 for the idle time before blanking, and xfconf-query -c xfce4-screensaver -p /lock/delay -n -t int -s 30 for the extra delay before the lock engages. Raise the display blank to match with xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/blank-on-ac -n -t int -s 60. The effective lock time is roughly the idle delay plus the lock delay.

To disable the lock entirely: in Settings → Screensaver untick Enable Screensaver and Lock screen, and in Settings → Power Manager → Display set Blank after to Never. The terminal equivalent is xfconf-query -c xfce4-screensaver -p /saver/enabled -n -t bool -s false, xfconf-query -c xfce4-screensaver -p /lock/enabled -n -t bool -s false, and xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/dpms-enabled -n -t bool -s false, followed by xset s off; xset s noblank; xset -dpms to stop X11 blanking in the current session. Note that disabling the lock leaves the machine unlocked whenever you step away, so raising the timeout is the safer choice for most users.

You can support Kodachi financially through documented channels: direct cryptocurrency donations (Bitcoin, Monero, USDT, BNB, BUSD, Dogecoin, Litecoin, Ripple, Polkadot and more - donate directly with crypto for maximum privacy), and third-party donation services NOWPayments (nowpayments.io/donation/linuxkodachi) and Donorbox (donorbox.org/kodachi). You can also purchase a Premium or Dedicated license (an annual license covering 12 months of all updates, no auto-renewing subscription, anonymous payment including Monero supported). Donations help sustain the free personal-use tier and shared VPS infrastructure but do not grant license keys or premium access.

Yes. Beyond donations and licenses, genuinely helpful word-of-mouth support includes sharing your experience on social media (X/Twitter, LinkedIn), creating YouTube tutorials or blog write-ups, and spreading the word in privacy communities so more people discover the project. You can also participate in the Discord community (https://discord.gg/KEFErEx) for real-time support and discussion, report bugs and submit feature requests there, and contribute on GitHub if you have the technical skills. These are real ways to help even if you cannot contribute money.

No. The documentation is explicit that donations help sustain the free personal-use tier and shared VPS infrastructure but do NOT grant license keys or premium/dedicated access. Premium and Dedicated are separate annual licenses covering 12 months of all updates (including across major versions), with no auto-renewing subscription; after 12 months your last ISO keeps working and you renew only to continue updates and managed-node access. License purchase requires no registration or account - you simply buy a key (anonymous options like Monero are supported) and activate it via online-auth or the dashboard under About > Premium License.

No. Personal use does not require a paid license - only commercial, professional, or organizational use requires one. All tiers (free, Premium, Dedicated) get the identical hardened OS and the full dashboard (Circle + Lite + Advanced); the only difference is backend VPS infrastructure density and isolation. Premium offers low-density nodes across multiple premium servers and Dedicated provides a fully isolated VPS, both as annual licenses (12 months of all updates), and neither includes a contractual SLA or uptime guarantee.

Community support is available via the Kodachi Discord at https://discord.gg/KEFErEx and GitHub at github.com/WMAL. No registration or account is required to use Kodachi - even purchasing a license needs no email (the key is shown on screen, and anonymous payment via Monero is supported). Paid tiers get best-effort priority triage, but this is not an SLA, and all users receive identical security features. Live service status is at /apps/status.php and a warrant canary at /tools/warrant.html.

Yes. Kodachi has been independently developed since 2013 and is trusted by privacy-conscious users worldwide. The current line is version 9.0.1, and the support model (donations and optional license keys) exists to sustain ongoing development while ensuring every user - free or paid - receives identical security features. A public warrant canary and live system-status page are maintained on kodachi.cloud.

No. All editions are free only for personal, educational, and research use. Commercial, professional, or organizational use requires a paid license (Premium or Dedicated), which include commercial usage rights. The feature comparison explicitly marks commercial use as not allowed on the Free tier.

Backend infrastructure quality, not software capability. Every tier gets the identical OS, the full dashboard (Circle + Lite + Advanced), and all updates; the difference is backend density and isolation - Free shares one crowded VPS pool, Premium uses low-density nodes spread across multiple premium servers for more consistent performance and a choice of exit IPs, and Dedicated provides a fully isolated VPS per customer. Paid tiers also add commercial usage rights and priority support.

The Free tier runs on high-density shared infrastructure with a monthly bandwidth allocation. When a shared node hits its monthly cap, service for that node pauses and resumes the next billing cycle or when capacity frees up. Paid plans have higher allocation and fewer users per node, so they are far less likely to be exhausted.

No. Premium and Dedicated are annual licenses: 12 months of all updates, including across major versions. A new major version that ships during your active license is included at no extra cost. After 12 months your last ISO keeps working; you renew only to keep receiving updates and managed-node access.

It is an annual license billed once, not an auto-renewing subscription - nothing recurs unless you choose to renew. Kodachi uses semantic versioning (Major.Minor.Patch); your active license covers 12 months of all updates, including across major versions (for example a 10.0.0 that ships during your term). After 12 months your last ISO keeps working; renew to continue updates and managed-node access.

License activation is managed by online-auth (Dashboard: About > License Manager). On the same active install on the same PC no release is needed. Before reinstalling or moving to another PC, release the license on the old system first ('sudo online-auth release-license' in the terminal, or the Release License button in the Dashboard), then activate again on the new system. If you have already wiped the old machine, open the web License Portal (link on your purchase-complete page, or the link icon in Dashboard > About > License Manager), go to the Devices panel, click the release icon, type RELEASE to confirm, and the seat is freed immediately so you can activate on the new machine.

All cryptocurrency transactions are final and non-refundable, and no separate refund policy or money-back guarantee is described for any payment method. Treat purchases as non-refundable.

No. There is no SLA on any tier (Free, Premium, or Dedicated). The commitment is continuous updates, best-effort VPS availability, and infrastructure maintenance. Priority support means paid requests are triaged ahead of free ones on a best-effort basis only and does not constitute an SLA.

No. There is no registration, no account creation, and no personal data required. The license key is delivered instantly on-screen, and for full anonymity you can pay with Monero (XMR).

Dedicated is $600 per device per year with a minimum of 5 devices. The minimum exists because Dedicated includes a fully isolated VPS, and the baseline device count covers the infrastructure cost of that exclusive instance. By default all your devices (up to 100) run on a single isolated VPS with a default country and provider. If you want a specific country or provider, or want to isolate groups of devices on their own servers, your plan lets you split into up to one VPS per 10 devices, each provisioned in a country and provider of your choice (for example 20 devices on one server and 10 on another). Premium is $99 per device per year with no such minimum.

Binding microsocks/V2Ray to 0.0.0.0 makes the proxy reachable by every device that can route to the server - an open-relay risk. Kodachi's microsocks uses ports in the 30050-30054 range; restrict access with firewall rules that allow only trusted IPs and drop the rest, and isolate the proxy on a dedicated/segmented network.

You do not need a license for personal use - Kodachi is free for individuals, and donations are entirely separate from licensing (they do not grant license keys, premium, or dedicated access). To donate any amount you like, use the Donate section of the support page - the same page used for license purchases. It offers direct cryptocurrency donations (Bitcoin, Monero, USDT and more, for maximum privacy) and the third-party services NOWPayments and Donorbox. Any contribution helps sustain the free personal-use tier and the shared VPS infrastructure.

Yes. Every paid license comes with a private web License Portal where you paste your license key (no account and no email needed, the key itself is your login) and instantly see everything about your purchase: your tier (Premium or Dedicated), how many seats you bought and which ones are activated, when your key expires shown as a countdown gauge, whether it is time-based or version-based, the devices it is active on, the price you paid and the purchase date, and your full transaction history and download links. If you have a group order with multiple keys, paste them all on separate lines and the portal displays all your licenses together in one view.

You can also release a license from the portal when you need to move to a new PC: find the Devices panel, click the release icon, type RELEASE to confirm, and the seat is freed immediately so you can activate on another machine. This is especially useful if you no longer have access to the old device.

The portal never shows your activation IP addresses. For security it is rate-limited: after 10 incorrect submissions it locks for 1 hour, and if you ever get stuck you can contact me on Discord or by email. You do not need to hunt for the address: the portal link is shown automatically on your purchase-complete page the moment your payment is confirmed. You can also open it directly from the Kodachi Dashboard (About, License Manager, then the link icon next to your key). Save it to your favourites and you can return to it anytime.

Yes. Beyond the standard tiers, Kodachi can produce a bespoke build as a paid service. A custom Live ISO can ship with the applications you choose pre-installed (for example ONLYOFFICE, Twinkle, Dolphin Anty, KolourPaint, or an Android emulator), with amnesic non-persistent behavior or as an installable image, with the installer enabled or fully removed so employees cannot install to disk, with additional system languages and locales (such as Ukrainian), and with configuration hardening to your specification. You can also have a private dedicated VPS provisioned in the country and with the provider you require (for example a specific NATO-member jurisdiction), running the protocols you choose.

The image ships with no personal accounts, browser sessions, saved passwords, or customer data baked in, is cryptographically signed, and boots reliably from USB SSD or USB flash on ordinary UEFI and BIOS PCs. Builds are produced for lawful, defensive, educational, and privacy-protection purposes. Tell me your requirements (a short, non-sensitive outline is enough to start) and I will study the scope and feasibility and send you a fixed, per-project price quote before any work begins. See the Custom ISO Builds & Private VPS section on the Support page for full details, and contact me on Discord at https://discord.gg/KEFErEx.