What Kodachi Does & How to Fix It

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. The Terminal Server edition includes 92 pre-built security workflows and supports unlimited custom workflows via the workflow-manager binary, with ready-made initial setup profiles for protocols like WireGuard, OpenVPN, Dante and Tor stacking. On Desktop, the Full-mode command queue lets you drag commands from any service tab, reorder them and run them sequentially or in parallel, while the Kodachi Dashboard's AutoShield first-boot wizard automates a configurable hardening sequence.

Yes. Kodachi 9 ships KAICS (an 8-binary plain-English CLI), an ai-gateway for policy-firewalled agent execution, and kodachi-claw (a Tor-anonymous AI agent runtime). 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, health/emergency control, authentication and a local AI stack. On Desktop the Tauri+Svelte dashboard orchestrates 517+ commands across 24 Rust binaries with no GUI freezing. The terminal-only base set is a leaner 19-binary build (the Conky telemetry binary 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.

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.

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/Linux-Kodachi. 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/Linux-Kodachi. 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://www.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/Linux-Kodachi.

Yes. Kodachi publishes a regularly refreshed warrant canary at https://www.kodachi.cloud/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.

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 https://www.kodachi.cloud/apps/os/install/kodachi-debug-collector.sh | sudo bash, or skip the category menu and collect everything with curl -sSL https://www.kodachi.cloud/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 https://www.kodachi.cloud/wiki/bina/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 https://www.kodachi.cloud/apps/os/install/kodachi-binary-install.sh | bash, followed by the dependencies installer with sudo: curl -sSL https://www.kodachi.cloud/apps/os/install/kodachi-deps-install.sh | sudo bash, and finally confirm with integrity-check check-version.

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 SourceForge location 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.

No, that is its purpose: permission-guard detects unauthorized permission changes and restores correct ownership across critical Kodachi paths. It only causes problems during installs/updates when it conflicts with files being replaced, which is why you stop it before updating. For normal use leave it running; to modify protected files, stop the daemon first and restart 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 https://www.kodachi.cloud/wiki/bina/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.

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 92 ready-to-use built-in profiles in dashboard/hooks/config/profiles/ and supports unlimited custom workflows.

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 Tauri+Svelte 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.

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.

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.

No. The Debug Collector deliberately does not capture IP addresses, passwords, browsing data, or personal files, and WiFi credentials and MAC addresses are auto-redacted. You can also deselect categories before collection. It gathers boot logs, hardware specs, network config, and Kodachi service status into a zip on your Desktop for support.

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) is a Desktop XFCE add-on and is intentionally not part of the terminal-only base set, because the Terminal edition has no GUI/desktop. The base Terminal ISO ships the core binaries minus the desktop-only ones; conky-status is present only in Desktop XFCE builds.

The base Terminal manifest bundles only kodachi-claw and zeroclaw as agent runtimes (plus the optional zeroclaw-desktop GUI); the full KAICS suite (ai-cmd, ai-gateway, ai-trainer, ai-learner, ai-admin, ai-discovery, ai-scheduler, ai-monitor) is an optional add-on, not part of the base ISO. The commands are documented for completeness but require installing the KAICS add-on to be available.

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.

The Kodachi Dashboard is the central control application built with Tauri 2 and Svelte 5 that orchestrates 517+ commands across 24 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 517+ commands across 24 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. 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.

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.

Yes. In Settings, "Always on Top" pins the dashboard above all other windows. Under Startup, "Start Minimized" launches it hidden in the system tray, and "Auto-start on Boot" launches it automatically at login. The System Tray settings let "Close to Tray" minimize the dashboard instead of exiting it, and you can show or hide the tray icon independently.

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 517+ commands across 24 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 517+ 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 the Kodachi Dashboard's guided first-boot setup wizard on the Desktop edition. It does not launch on its own - the Kodachi Dashboard auto-starts at login and presents AutoShield as the first-boot setup route on its welcome screen; you can also re-open it any time from the dashboard's shield icon. It walks through 9 configurable security steps with a countdown timer, live telemetry and a before/after identity comparison. 7 steps 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); when the countdown reaches zero it auto-executes the enabled steps.

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. The Kodachi Desktop dashboard has three switchable interface modes plus AutoShield, its first-boot setup wizard. Circle (720x720, gamified security ring, ~230MB RAM) is for beginners and quick security setup. Lite (1128x774, compact command center, ~230MB RAM) is for intermediate daily operations. Full (1800x1000, multi-panel workstation with command queue and drag-and-drop, ~380MB RAM) is for advanced power-user workflows. You can switch modes from the header without relaunching and your last choice is remembered. AutoShield is a guided wizard route the Dashboard offers on first boot (and re-openable from the header shield icon) - it runs a multi-step hardening sequence rather than being a persistent interface mode.

Start in Circle if you just want quick security checks via the gamified ring, or Lite for everyday operations; the docs recommend starting in Lite and upgrading to Full only when you need the Advanced service tabs or command queuing. AutoShield - the Kodachi Dashboard's first-boot setup wizard, offered on the welcome screen and re-openable from the header shield icon - is the easiest entry point of all, walking you through the hardening steps automatically. The AI Chat button works in Circle, Lite and Full, so you can ask for command help without leaving your current view.

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.

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.

Kodachi Claw is an anonymous autonomous AI agent runtime. It is a single static Rust binary that wraps an AI agent engine with Kodachi's full anonymity stack so that every API call, every model request, and every channel message is routed through embedded Tor circuits. It exposes 50+ AI provider integrations and 40+ communication channels, so the agent can do real work while staying untraceable. It is an independent runtime, not a KAICS sub-binary.

It builds a full Arti Tor stack into the binary and runs a multi-circuit pool (default 10 instances) with load balancing across four circuit strategies (round-robin, random, least-used, sticky). On top of that it adds MAC, hostname, and timezone randomization, IP and DNS leak verification, an OPSEC outbound filter that redacts identity leaks, optional kernel-level network namespace isolation via oniux, and restore-on-exit cleanup. The result is an AI agent that cannot be fingerprinted or traced back to you.

ZeroClaw is the ultra-lightweight upstream Rust AI agent engine - fast, tiny, runs on cheap hardware, but it operates on the open internet. Kodachi Claw is forged from that same ZeroClaw engine and adds Kodachi's anonymity layer on top: embedded Tor with a circuit pool, MAC/hostname/timezone randomization, the OPSEC outbound filter, oniux namespace isolation, and IP/DNS leak verification. In short, ZeroClaw gives you the agent; Kodachi Claw makes that same agent invisible.

They are a family of AI agent runtimes: OpenClaw is the original Node.js project, ZeroClaw the ultra-light Rust fork, NullClaw the smallest (Zig, ~678 KB), PicoClaw a tiny Go agent, IronClaw a Rust agent with WASM-sandboxed tools, and NanoClaw a TypeScript container-secured agent. All of them give you an AI agent. Kodachi Claw is the only one that hardens that agent for anonymity with embedded Tor, identity randomization, and an OPSEC filter.

Both ship. Kodachi bundles kodachi-claw (the anonymity-hardened runtime) and zeroclaw (the upstream-compatible runtime) as separate binaries. They are part of the base terminal manifest and the binary package, so you can use either one directly depending on whether you want the anonymity layer or the lighter upstream behavior.

Yes. A zeroclaw-desktop GUI (a Tauri companion app) is bundled alongside the command-line zeroclaw and kodachi-claw binaries. So you genuinely have a choice: run kodachi-claw for full Tor anonymity, run the upstream-compatible zeroclaw, or use the zeroclaw-desktop graphical app. All three ship together in the package builds.

The agent runtimes kodachi-claw and zeroclaw ship in the base terminal manifest, but the KAICS tools (ai-cmd, ai-trainer, ai-learner, ai-admin, ai-discovery, ai-scheduler, ai-monitor, ai-gateway) remain optional add-ons rather than part of the terminal-only base set. The Desktop XFCE edition ships the full Kodachi binary suite. So out of the box you always have the Claw agents; the natural-language KAICS workflows are available to enable as an add-on.

You need the kodachi-claw binary plus its matching .sig signature file - the public key is embedded at compile time and the binary verifies its own signature on startup, refusing to run if the .sig is missing. Place the .sig in the same folder as the binary or in results/signatures/ relative to it. It typically runs with sudo because identity randomization (MAC/hostname/timezone) and namespace isolation need elevated privileges, and you configure a provider via the onboard step.

No external setup. Kodachi Claw embeds the Tor stack and integrates Kodachi services - online-auth, ip-fetch, tor-switch, routing-switch, oniux and others - directly as in-process Rust libraries rather than calling external binaries. online-auth with device-ID verification, auto-recovery, and session persistence is built in, so there is no separate auth binary to run. You just supply your AI provider credentials during onboarding.

In the default multi-circuit mode, Kodachi Claw runs a pool of Tor instances (default 10) and load-balances requests across them, which gives throughput and circuit diversity. In isolated mode (--mode isolated) it uses oniux to create a Linux network namespace that forces all traffic through Tor at the kernel level, so no DNS or IP leak is possible even from misbehaving child processes or libraries. Isolated mode is the strongest anonymity option.

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.

It enforces a three-tier risk classification. Passive (read-only) commands run freely. Active (system-changing) commands require explicit --confirm. Dangerous (destructive) commands such as wipe-logs, panic-hard, or block-internet require both an environment variable (KODACHI_PENTEST_MODE=true) and explicit confirmation. Dry-run validation is always allowed, so an agent can safely plan first and only execute after the proper gates are met.

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, kodachi-claw, nullclaw, openclaw, picoclaw, nanoclaw, claude-code, gpt, gemini, and open-interpreter. The name zeroclaw is accepted as an alias and normalizes internally to kodachi-claw, so both names work in --agent-id flags. 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 need an environment variable plus explicit confirmation. 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.

It is built in. Kodachi Claw embeds an Arti-first Tor runtime directly in the binary with a multi-circuit pool (default 10 instances) and configurable circuit-assignment strategies (round-robin, random, least-used, sticky), plus an isolated per-request mode that gives each request its own circuit. It also performs automatic MAC, hostname and timezone randomization, IP and DNS leak verification, and runs an OPSEC filter that redacts outbound identity leaks from agent messages, with HMAC-SHA256 tamper-evident audit logging. Identity is restored on shutdown.

Yes. Kodachi Claw can run agent operations inside an OS sandbox using multiple backends - Landlock, Bubblewrap, Firejail, or Docker - and adds full network-namespace isolation via oniux in its isolated mode. It also keeps secrets in a ChaCha20-Poly1305 encrypted store and runs its cron job scheduler against security allowlists, so an autonomous agent is confined rather than given free rein over the host.

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 https://www.kodachi.cloud/dns.html.

Yes, two forms. DNSCrypt is fully integrated - enable it with sudo dns-switch dnscrypt-enable 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. 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. Connect a VPN/proxy first (e.g. sudo routing-switch connect wireguard), then layer Tor with sudo routing-switch connect tor --force so traffic flows through both for double encryption. 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.

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. routing-switch can export any configured protocol so you can carry the same connection to a mobile device. 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.

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. tor-switch runs multiple Tor instances and balances traffic across them at the nftables kernel level with three modes: round-robin (each new TCP flow goes to the next instance, persisted via conntrack ct mark), weighted (instances get a configurable share of flows), and consistent-hashing (a source IP always maps to the same instance, useful for banking/streaming sessions that block IP changes). It can additionally generate HAProxy configurations with roundrobin, source, leastconn or random algorithms for application-level balancing.

Yes. routing-switch supports a double-layer setup where you first connect a VPN/proxy protocol (for example sudo routing-switch connect wireguard) and then route that connection through Tor, so your traffic goes through the VPN tunnel and then the Tor network for two independent anonymity layers. The connection verification shows Tor routing with the VPN still active. This is an explicit, user-selected configuration rather than something enabled silently.

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 - 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.

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%. 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.

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.

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 https://www.kodachi.cloud/, the DeepTrace IP report at https://www.kodachi.cloud/ip.html, the DNS Leak Test at https://www.kodachi.cloud/dns.html, and a Browser Fingerprints test at https://www.kodachi.cloud/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.

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.

Boot-time LUKS nuke only works on installs that keep the LUKS unlock prompt in initramfs. If you used the Calamares GUI encrypted install, the first LUKS 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 nuke password destroys LUKS keys and needs an actual LUKS-encrypted partition, 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. You also need 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.

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.

The score is a percentage of applicable points, not absolute points. The scorer detects a live ISO (boot=live in /proc/cmdline or /run/live present) and drops disk encryption, swap encryption, auto-updates, encrypted containers, and backup encryption out of the maximum instead of failing them, so a live user who maxes every applicable check still reaches 100%. An installed system with those protections enabled has the same 100% ceiling - installation by itself is not rewarded.

The denominator is adaptive. Checks that physically cannot apply are excluded from the maximum rather than counted as failures: live-ISO sessions skip disk/swap encryption, auto-updates, backup and encrypted-container checks; BIOS-only machines skip Secure Boot; swapless systems skip swap encryption. So a fraction like 57/82 is the same percentage standing it would be against a reduced maximum - nothing is wrong with the install.

That is correct and intentional. On the live ISO the disk-encryption check is N/A because there is nothing to encrypt, so it drops out of the maximum. On an installed system the check becomes applicable, and an unencrypted disk genuinely fails it, lowering the percentage. That gap is the real cost of an unencrypted disk; enable LUKS at install time to recover those points.

No. 60-75 (Fair to Good) is perfectly adequate for daily use, and a VPN + DNSCrypt + firewall baseline is already far more secure than most operating systems. Pushing to 90+ enables aggressive features (disabled WiFi, blocked USB, killed Bluetooth, full kernel hardening) meant for high-threat scenarios, and combining Secure Boot + LUKS + full hardening + Tor can break services, hide hardware, and greatly slow boot. Only target 90+ for truly critical use, accepting reduced usability.

Context detection skips checks that physically cannot apply and removes them from the denominator instead of failing them - headless systems skip Bluetooth/webcam, WiFi-only systems skip WiFi, swapless systems skip swap encryption, BIOS-only machines skip Secure Boot. A missing-by-hardware check never drags your score down by design.

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'.

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 92+ ready-to-use built-in profiles, and you can add your own.

Yes. health-control provides targeted secure-wipe operations: sudo health-control wipe-file --file <path> (with a configurable --passes count, for example --passes 7), sudo health-control wipe-directory --path <dir>, sudo health-control wipe-batch --paths a,b,c, plus dedicated wipe-logs and wipe-browser-data commands. These overwrite data so it cannot be recovered, so they are surgical alternatives to a full panic/nuke. All wipe operations require sudo and are irreversible.

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.

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 (one-time per major version, no recurring 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 one-time purchases per major version (e.g. 9.x.x), with no recurring subscription and a 60-day grace period for a free upgrade if a new major version releases shortly after purchase. 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) receive identical OS security capabilities; the only difference is backend VPS infrastructure density and isolation. Premium offers a low-density shared backend and Dedicated provides a fully isolated VPS, both as one-time purchases per major version, 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 https://www.kodachi.cloud/apps/status.php and a warrant canary at https://www.kodachi.cloud/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 identical OS features and updates; the difference is backend density and isolation - Free uses crowded shared VPS, Premium uses low-density shared VPS for more consistent performance, 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, you are covered by the 60-day grace period. A license is a one-time purchase per major version (all 9.x.x releases). If a new major version releases within 60 days of your purchase you get a free upgrade; only major upgrades outside that window (e.g., 10.x.x) require a new purchase.

It is a one-time purchase, not a recurring subscription. Kodachi uses semantic versioning (Major.Minor.Patch); your purchase covers all patch and minor updates within the major version you bought (all 9.x.x). A new license is only needed when the major version changes, for example when 10.0.0 ships.

License activation is managed by online-auth (Dashboard: About > Premium License). 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'), then activate again ('sudo online-auth activate-license --key "YOUR-KEY"'); release before wiping or switching devices so the key is free to reactivate.

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. Donations help sustain the free personal-use tier and shared infrastructure, but they explicitly do not grant license keys, commercial usage rights, premium or dedicated infrastructure access, or priority support. To get those you must buy a Premium or Dedicated license.

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 $349 per device per major version with a minimum of 5 devices. The minimum exists because Dedicated includes a fully isolated VPS per customer, and the minimum device count covers the baseline infrastructure cost of that exclusive instance. Premium is $139 per device per major version 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.