Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/jossephus/chuchu/llms.txt

Use this file to discover all available pages before exploring further.

Chuchu is actively developed and contributions are welcome. The project author daily-drives Chuchu, which means real-world bugs get found and fixed quickly — and it means your bug reports and pull requests land in an app that someone actually uses. Whether you fix a crash, improve the UI, or just file a detailed issue, you are helping move the project forward. The project is hosted at github.com/jossephus/chuchu.

​
Ways to contribute

Report a bug

Open an issue on GitHub with steps to reproduce, your Android version, and the Chuchu version.

Submit a pull request

Fork the repository, create a branch, implement your change, and open a PR.

Test and give feedback

Use Chuchu as your daily SSH client and report anything that feels wrong or breaks.

Build from source

Set up a local build environment to develop and test changes before submitting.

​
Reporting bugs

Good bug reports save significant debugging time. When opening an issue, include:
  • Steps to reproduce — the exact sequence of actions that triggers the problem
  • Android version — Settings → About phone → Android version
  • Chuchu version — visible in the app settings or from the GitHub release page
  • What you expected vs what actually happened
  • Logcat output if the app crashed — run adb logcat -s ChuKittySSH to capture native SSH logs

​
Submitting pull requests

1

Fork and clone

Fork the repository on GitHub, then clone your fork locally.
git clone https://github.com/YOUR_USERNAME/chuchu.git
cd chuchu
2

Set up your build environment

Follow the instructions in Build from source to compile the native library and run the app on a device.
3

Create a branch

Use a descriptive branch name that summarises the change.
git checkout -b fix/ssh-reconnect-crash
4

Implement your change

Make your changes following the code style guidelines below. Keep commits focused — one logical change per commit.
5

Open a pull request

Push your branch and open a PR against main. Describe what the change does and why, and link any relevant issues.
git push origin fix/ssh-reconnect-crash

​
Code style

​
Zig

The Zig source lives in zig-src/src/. Follow these conventions when modifying or adding Zig code. Naming:
ConstructConventionExample
Functions and methodscamelCaseconnectSocket
Variables and parameterssnake_casesocket_fd
Types, structs, enumsPascalCaseNativeSshSession
ConstantsSCREAMING_SNAKE_CASELOG_TAG
Struct initialization — prefer explicit type annotation with anonymous literals: 
const session: NativeSshSession = .{ .socket_fd = -1 };  // preferred
const session = NativeSshSession{ .socket_fd = -1 };     // avoid
File structure — every module should follow this order:
  1. //! module doc comment
  2. const Self = @This(); (for self-referential types)
  3. Imports: std → builtin → project modules
  4. const log = std.log.scoped(.module_name);
Method order within a struct: 
init → deinit → public API → private helpers
Function length — soft limit of 70 lines per function. Centralise switch/if control flow in parent functions and push pure computation into helpers. Documentation — use /// for public API doc comments, // for implementation notes. Explain why the code exists, not just what it does. Memory — pass allocators explicitly. Use errdefer to clean up on the error path. The native layer uses std.heap.c_allocator throughout. 
/// Connects to the remote host and starts the SSH handshake.
pub fn connect(self: *NativeSshSession, host: []const u8, port: u16) !void {
    // ...
}

​
Kotlin

The Android app follows standard Android and Kotlin conventions:
  • Jetpack Compose for all UI — no XML layouts
  • StateFlow for reactive state, observed with collectAsStateWithLifecycle in Compose
  • ViewModels scoped to the navigation destination
  • Room for all local persistence — no raw SQLite
  • Coroutines with structured concurrency; TerminalSessionEngine runs on a dedicated single-thread dispatcher named terminal-session

​
Progress tracking

The project tracks feature progress in .plans/progress.txt. When you complete or materially advance a feature, update that file with a dated entry describing what changed. Treat the progress update as part of the same commit as the code change — do not defer it.
The project author daily-drives Chuchu as their primary SSH client, so bugs that affect real usage are taken seriously and prioritised quickly. If something annoys you in daily use, it is worth filing an issue even if you cannot reproduce it reliably.

Build docs developers (and LLMs) love

Get started for freeTalk to us