Codex guide

Connect FlightSweeper to Codex

Configure FlightSweeper's remote MCP server in Codex and keep final approval, traveler data, and payment on FlightSweeper.

OAuth recommended · token fallback

Authorize with OAuth when the client environment supports it. Use a revocable 30-day personal token only as an advanced fallback; two tokens may overlap during rotation.

Best for

Codex users who want live flight tools alongside their normal work without autonomous purchasing.

Starter prompt

Use FlightSweeper to search a flexible round trip within the next six months. Compare the live options and prepare hosted checkout only after I approve one exact quote.

Setup flow

Every client uses the same Streamable HTTP endpoint and documented public tool set. The primary book_flight action hides the internal intent and approval stages; approval and payment stay hosted.

OAuth access tokens expire after 10 minutes and refresh tokens rotate. If this environment requires the personal-token fallback, the secret is shown once, expires after 30 days, and can be revoked from Account → Integrations.

A personal token is a compatibility path for headless or restricted environments, not the recommended first setup.

1

Add https://flightsweeper.com/api/agent/mcp as a Streamable HTTP server in ~/.codex/config.toml.

2

Authorize Codex with your FlightSweeper account using OAuth.

3

Use a revocable personal token only if OAuth cannot run in that environment.

4

Use `codex mcp list` to confirm the server and its documented public tools before a live search.

5

Use book_flight after selecting an exact quote; enter passenger/card data only on FlightSweeper, then resume with the returned intent ID.

Tool permissions

Every client should keep the same transaction boundary: search can happen in the agent, but booking happens after the traveler confirms a hosted checkout page.

Fare-bearing results include all-in total, currency, quotedAt, expiresAt, and refresh state.
book_flight is resumable: it binds the selected quote, returns the hosted approval/payment action, and resumes to canonical confirmation.
cancel_booking_intent applies only to approved, unpaid intents. Paid-order servicing and refunds stay hosted.
Booking status, policy summaries, and opaque traveler summaries are scoped to the authenticated owner.