Flightmapify
WarnAudited by ClawScan on May 10, 2026.
Overview
FlightMapify appears to generate flight maps as described, but it can automatically use local FlyAI credentials, start persistent web servers, serve the whole workspace, and kill other processes on a port without clear approval.
Review carefully before installing. Use a dedicated FlyAI key, run it only in a workspace without sensitive files, choose ports that are definitely unused, and be prepared to stop the background servers manually. There is no evidence of direct exfiltration in the provided artifacts, but the local server and process-control behavior should be tightened.
Findings (6)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A normal invocation could terminate another local application or service that happens to use the chosen port.
The HTTP server startup path may automatically kill any process using the selected port instead of asking the user or choosing another port.
print(f"Port {current_port} is occupied by another process, killing it...") ... subprocess.run(['kill', '-9', pid], capture_output=True)Do not automatically kill unrelated processes; prompt the user, select a different port, or only stop a verified FlightMapify-owned process.
Files in the workspace may become accessible through the local web server for as long as it runs, which is broader than needed to view one map.
The skill starts a generic HTTP file server rooted at the whole OpenClaw workspace, not just the generated flight-map file or a narrow assets directory.
cmd = [sys.executable, "-m", "http.server", str(current_port)] ... cwd=WORKSPACE_DIR
Serve only the generated output directory/file, bind explicitly to 127.0.0.1, and clearly warn users before exposing a workspace directory.
Users with an existing FlyAI login/config may unknowingly have that account key used for searches and quota consumption.
When the environment variable is absent, the server reads a local FlyAI config credential and passes it to the flyai subprocess.
config_path = os.path.expanduser('~/.flyai/config.json') ... user_api_key = config_data.get('api-key', '') ... env['FLYAI_API_KEY'] = api_keyDeclare the credential/config path in metadata and documentation, ask before using stored credentials, and provide an opt-out or dedicated-key workflow.
While the server is running, other browser pages may be able to call the local flight-search API and consume provider quota, though the code does not show direct API-key disclosure.
The local flight-search API enables cross-origin browser access for all routes rather than limiting requests to the generated map page.
app = Flask(__name__) CORS(app) # Enable CORS for all routes
Restrict CORS to the generated localhost origin/port and consider adding request-origin checks or a local nonce.
The server may continue running after the command finishes, which is expected for an interactive map but should be visible and easy to stop.
The flight-search server is launched as a detached background process with output suppressed.
process = subprocess.Popen(... stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL, preexec_fn=os.setpgrp, env=env)
Show users how to stop the servers, record PIDs, and provide a cleanup command.
The skill may use whatever flyai binary and Python packages are already present in the environment, which makes provenance and compatibility less clear.
The code depends on Flask/flask_cors and a flyai executable, but the registry requirements and install spec do not declare these runtime dependencies.
from flask import Flask, request, jsonify from flask_cors import CORS ... cmd_direct = ['flyai', 'search-flight',
Declare required binaries/packages and versions, or document that the skill requires a trusted existing FlyAI installation.
