FlightDesk CLI

The command-line interface for FlightDesk — AI task management for Claude Code sessions.

What is FlightDesk?

FlightDesk helps development teams track and manage work performed by Claude Code remote sessions. It provides:

• Task lifecycle tracking from dispatch to merged PR
• Automated branch detection via GitHub webhooks
• Multi-organization support for developers working across clients
• Integration with GitHub, SonarQube, and other review tools
• Preview environment management

Learn more at flightdesk.dev

Installation

npm install -g flightdesk

Quick Start

# Configure your FlightDesk API credentials
flightdesk init

# Register a Claude Code session with a task
flightdesk register <task-id> --prompt "Fix the auth bug"

# Check task status
flightdesk status

Commands

| Command | Description | | --------------------- | -------------------------------------- | | flightdesk init | Configure API credentials | | flightdesk register | Register a session with a task | | flightdesk task | Create, list, and manage tasks | | flightdesk status | Show status of all active tasks | | flightdesk prompt | Get prompts ready to paste into Claude | | flightdesk org | Manage organization connections | | flightdesk context | Show current repo/org mapping | | flightdesk sync | Refresh project-to-repo mappings | | flightdesk project | Project management commands | | flightdesk preview | Preview environment management |

Multi-Organization Support

Developers working across multiple clients can connect multiple FlightDesk organizations:

# List connected organizations
flightdesk org list

# Switch active organization
flightdesk org switch <name>

# Check which org maps to current repo
flightdesk context

The CLI automatically routes tasks to the correct organization based on the Git repository you're working in.

Documentation

Full documentation available at flightdesk.dev/docs

License

This software is proprietary. See flightdesk.dev for licensing information.

Command center and Qalatra dispatch

FlightDesk records requests; Qalatra owns execution. Use an invited user marked AGENT by an organization administrator, and authenticate the CLI with that user's organization-scoped token. Node URLs and bindings are private and are never included in people lists.

flightdesk agent-bind --path agents/shi --node https://qalatra.example.com
flightdesk dispatch list
flightdesk dispatch update REQUEST_ID --status ACKNOWLEDGED --job QALATRA_JOB_ID
flightdesk dispatch update REQUEST_ID --status RUNNING
flightdesk comment TASK_ID --body "Implementation finished; checks passed."
flightdesk dispatch update REQUEST_ID --status DONE

Transitions are REQUESTED → ACKNOWLEDGED → RUNNING → DONE; any open stage may become FAILED. Updates and polling are restricted to the request's agent and the token's organization. Qalatra must deduplicate queued jobs by dispatch request ID before acknowledging. Polling is the contract; there is no outbound webhook or agent execution in FlightDesk.

Human organization owners/admins may explicitly request work:

flightdesk dispatch request TASK_ID --agent AGENT_USER_ID --kind PLAN --prompt "Prepare a plan"
flightdesk comment TASK_ID --body "Explain the tradeoffs" --ask-agent

MCP equivalents are bind_agent, list_dispatch_requests, update_dispatch_request, request_dispatch, add_task_comment, list_task_comments, and transition_work_status. list_tasks also accepts assigneeId and openDispatch. A normal comment, including an @agent mention, is stored as data and does not request execution.

Tasks expose a nullable runStatus (the coding run, written by GitHub webhooks and QA) and a phase — where the work is in the FlightDesk pipeline: BACKLOG, READY, PLAN, PLAN_REVIEW, BUILD, WAITING, CODE_REVIEW, MERGE, RELEASE or DONE. The phases are the same on every project; a project's settings decide only whether each gate needs a human. transition_work_status takes phase. GraphQL status remains a deprecated alias for runStatus. General tasks have no run status and cannot enter GitHub or preview operations.