tesla_auth: generating Tesla API tokens through a real login flow

A token generator for your own vehicle

The stated purpose is to securely generate API tokens for third-party access to your Tesla. The word securely is doing specific work here, because the usual way people get a Tesla API token is to enter their account password into some third-party web page or app that then holds a live session to the car. tesla_auth takes a different route. It opens Tesla's own login flow in an embedded browser view, you type your credentials into Tesla's page rather than into the program's own dialog, and when the login completes the program extracts the resulting tokens for you to copy. The project supports MFA and Captcha through Tesla's native login flow, which is the technical heart of the approach, because a login that involves a one time code or an image challenge cannot be automated in a text field. The audience is Tesla owners who want to plug their car into a home automation stack, a charging monitor or a statistics service, and who would rather not hand their password to a third-party site.

A webview, an OAuth2 client and a clipboard

The dependency list in the manifest explains the design. There is an oauth2 crate at version 5.0.0 with the reqwest-blocking feature enabled, which is the token handling. There is wry at 0.56.0 with devtools enabled, and tao at 0.36, which together are the window and webview layer, and muda for the menu, since the copy, cut, paste and select all menu items need to exist for the keyboard shortcuts to work. The command line is parsed with argh, errors are handled with anyhow, and logging goes through log with simple_logger writing to stderr. The interface itself is minimal. You run the executable, you get a window with Tesla's sign-in page, you enter your account credentials and an MFA code if the account asks for one, and at the end you get a final window where you can select and copy the access token and the refresh token. There is no headless mode and no configuration file, which is a deliberate simplification rather than an omission.

Three switches, and a debugging flag that matters

The command line surface is small enough to describe in one breath. There is a debug flag, short and long, which prints debug output, a clear-browsing-data flag that clears browsing data at startup, a version flag that prints the version and exits, and the usual help output. The debug flag is the one that earns its place, because the troubleshooting section tells you to run it first: it prints the URLs the webview navigates to, which is usually enough to tell where a flow gets stuck. When a login does not complete, knowing the last URL the view reached separates the categories of failure. A view that never leaves the sign-in page is a cookie problem, while a view that lands on an access denied page from the CDN is a network reputation problem, and the debug output shows which of the two you have before you start changing anything.

Every platform needs a different webview

The platform section is the longest part of the documentation, because a webview is not something the operating system provides in a uniform way. On macOS, WebKit is native, so no additional dependencies are required. On Windows, the WebView2 runtime provided by the Microsoft Edge Chromium is used, which is why Windows 7, 8, 10 and 11 are all supported. On Linux you need WebKitGTK 4.1, and libxdo is used to make the predefined copy, cut, paste and select all menu items work. The version requirement is the hard part, because Ubuntu 22.04, Debian 12 and Fedora 36 are the earliest releases that ship WebKitGTK 4.1, and the README is explicit that on anything older neither the prebuilt binaries nor a local build will run. The install commands for the three main families of Linux distribution are short, and the Arch one installs the xdotool package that provides the same libxdo functionality:

sudo apt install libwebkit2gtk-4.1-dev libxdo-dev

and the Fedora equivalent pulls in gtk3-devel, webkit2gtk4.1-devel and xdotool.

Linux rendering needs the environment flags

The most specific troubleshooting entry covers a blank window, or a window that disappears immediately, on Linux. The cause is that WebKitGTK's accelerated rendering paths misbehave on a number of drivers, the NVIDIA proprietary one in particular, with symptoms such as a failure to create a GBM buffer or a protocol error dispatching to the Wayland display. tesla_auth therefore disables the DMA-BUF renderer by default, and if the window still does not come up there are three environment variables to try:

WEBKIT_DISABLE_COMPOSITING_MODE=1 tesla_auth   # turn off compositing entirely
GDK_BACKEND=x11 tesla_auth                     # run under XWayland
WEBKIT_DISABLE_DMABUF_RENDERER=0 tesla_auth    # opt back into the default renderer

The order matters, since each one disables a different layer of the graphics stack, and the third one goes the other way, putting the default renderer back. This is the part of the project that is most tied to a specific moment in the Linux graphics stack, and it is worth knowing before you start debugging a login that never appears.

Four failures with four different causes

The troubleshooting entries are more useful than most project documentation because each names a cause rather than a symptom. A login form that keeps returning to the sign-in page is almost always stale cookies from a previous session, and the fix is to start over with a clean profile using the clear-browsing-data flag:

tesla_auth --clear-browsing-data

An access denied page naming errors.edgesuite.net, which is Akamai, means the request was rejected by Tesla's CDN before it ever reached the login page, and the README calls that an IP reputation block that tesla_auth cannot influence, with the advice being to disconnect from a VPN or force a new public IP by power-cycling the router. TeslaMate reporting that tokens are invalid is a separate matter again, because the tokens have been pasted into TeslaMate, which then talks to auth.tesla.com itself, so a failure there makes TeslaMate report good tokens as invalid, and the fix is to read its logs and retry once the endpoints are healthy. And the macOS log line about a property value being invalid on a nil context is described as noise from the system input manager that any WebKit based app produces, with no effect on the login flow.

Building from source and the shape of the releases

The development section is three commands, and the split between building and installing is deliberate:

# Clone repository
git clone https://github.com/adriankumpf/tesla_auth
cd tesla_auth

# Build (debug version)
cargo build

# Install (release version)
cargo install --path . --locked

The manifest describes a Rust 2024 edition package at version 0.15.0, and the release profile is tuned for distribution rather than for speed, with debuginfo stripped, opt-level set to z to optimise for size, link time optimisation enabled and a single codegen unit. A separate dist profile inherits from release with thin LTO, which is the profile the dist tooling builds with, and the repository carries dist-workspace.toml and a build.rs that pulls in the static_vcruntime crate to link the C runtime statically on Windows. Prebuilt archives are published for macOS on Apple Silicon and Intel, for Linux on x86_64 and ARM, and for Windows, all from the releases page. The release history moves quickly, with 0.15.0 and 0.14.0 both published on 2026-08-10, 0.13.0 in April 2026, and the last push to main on 2026-09-14. The licence is MIT.

Editorial conclusion

tesla_auth suits a Tesla owner who wants to connect a third-party tool, such as a home automation project or a telemetry service, and who is willing to run a small native program on their own machine to mint the tokens. It is the wrong tool if you need continuous programmatic access without a person in the loop, since the flow is interactive by design and the tokens still expire, and it is unsuitable on a Linux system older than the stated WebKitGTK 4.1 baselines. Before using it, check that your distro actually ships WebKitGTK 4.1, because the README says neither the prebuilt binaries nor a local build will run on anything older, and remember that the tokens you copy out are a full account credential.

Frequently asked questions

Official sources

1. adriankumpf/tesla_auth on GitHub
2. Issues
3. License: MIT
4. README
5. Releases