Termux Dashboard

I wanted short stretches of phone time to begin with the right project, not with rebuilding context.

A short phone session can become useful work instead of setup time. The workflow stays local and inspectable, and it works with the terminal tools I already depend on instead of putting them behind another hosted service.

The need

Development from an Android phone loses momentum when reopening the right repository, remembering its state, and rebuilding a terminal workspace takes too many steps.

What made it nontrivial

The launcher has to coordinate tmux sessions, working directories, remembered choices, and Git state without damaging unfinished work. Rejoining an existing session should preserve it, while a fresh session still needs a predictable place to begin.

What I took responsibility for

I wrote the shell entry point, the tmux window flows, the project and script menus, the Git safeguards, the user-local state behavior, the documentation, and the repository's lint and smoke-test paths.

I took the workflow from the first shortcut into the selected repository. That included menu behavior, explicit directory handoff, session creation and reattachment, safe Git decisions, integration boundaries for external tools, and tests that observe what tmux actually did.

Engineering choices

Decisions that shaped the work

Keep the workflow local and legible

The launcher is an ordinary shell script around Termux and tmux. Its state lives in user-local files, and the important choices remain visible instead of being delegated to a remote service.

Preserve work on re-entry

A fresh launch creates a named set of windows, but reattaching preserves the existing tmux state. Explicit working-directory handoff keeps the selected repository as the place where the shell lands.

Make Git automation refuse unsafe shortcuts

The pull prompt appears only when the default branch is clean and behind its remote. Dirty, ahead, diverged, detached, or non-default states are left alone, and stale branches are never force-deleted.

Current substance

What exists now

Pinned and recent project and script menus, with a full-list path when the short list is not enough.
Fresh tmux workspace creation and reattachment, including an optional journal window and a repeatable project-window flow.
Git status summaries, fetch-and-prune handling, conservative stale-branch cleanup, and behind-only pull prompts.
A thin Codex alert window that calls the installed external command and handles missing commands, failed status calls, and malformed JSON without taking over that tool's responsibilities.

Checks and demonstrations

How I checked it

The repository's lint path runs Bash syntax checks and ShellCheck over the launcher and its tests.
Smoke scenarios use temporary repositories and tmux-observed pane output and working directories to check menus, reattachment, pull gating, stale-branch protection, and final directory handoff.
The public repository includes screenshots and a widget-to-repository demo clip showing the mobile entry flow.

Current limits

What this does not establish

Public installation is manual. The downstream installer used for Schuyler's personal setup is not part of this public repository.
This is a usable alpha. The installation path, interfaces, and documentation may still change.
The repository has no license at the reviewed revision, so its public source is available to read but not offered for reuse.

Status and reuse

Where the project stands

Usable alpha Public-readable

The repository is public to read, but it does not currently include a license granting reuse rights.

View Termux Dashboard

Related conversations

Problems this work gives us a starting point for

This project is most relevant when the difficulty is not inventing another platform, but making an existing set of local tools easier and safer to enter.

Mobile developer workflows built around existing terminal tools.
Local automation that needs to show state before it changes anything.
Thin control surfaces around another tool without copying or obscuring that tool's responsibilities.

Back to all builds

A real conversation

Tell me what you have in mind

I read these emails myself. Tell me what you are making, changing, exploring, or trying to repair. It helps to include:

what already exists and what is not working
what you want to change or make possible
the timing and approximate budget or exchange you have in mind
whether location, travel, shipping, or access to a hardware bench matters

Reaching out does not commit either of us to working together. It simply gives us a place to begin.

Email Schuyler GitHub LinkedIn