fbxctl
One Freebox control engine across a command line, terminal interface and native Mac app.
Native macOS interface · synthetic Demo captured 14 October 2026
Problem & context
Administering several Freebox devices means keeping the selected device, access mode and available evidence clear before making a change. A script, a terminal session and a native app need to follow the same operation rules. This is an unofficial tool, unaffiliated with Free or Iliad.
My contribution
Developed a shared typed engine for profiles, resource inspection and reviewed configuration changes. Connected a scriptable CLI and OpenTUI interface to that core, then built a SwiftUI Mac app around the bundled CLI. Added resource-based editing, a review of current and requested settings, and retained results tied to the selected device and access mode.
Decisions & tradeoffs
Keep one operation engine across all three interfaces.
Let each interface use its own presentation while sharing device identity, confirmation and result semantics. The native app delegates operations to its bundled CLI instead of maintaining a second set of router rules.
Bind a change to the exact reviewed device and current state.
Require an unexpired plan and exact confirmation, re-read before dispatch and reject changed or replayed plans. If a dispatched operation cannot be verified, retain an uncertain result that requires checking before another attempt.
Outcome
Implemented a consistent workflow for profiles, resource inspection and reviewed changes across CLI, terminal and native Mac interfaces. The presentation uses synthetic data from the local pre-release application.
Additional images
