Ship SAP faster.

Yes. The toolkit is GPL-3.0 open source on GitHub (v0.7.2, July 2026). We earn money helping you deploy, customise, and operate it.

Encrypted with Windows DPAPI on the developer's machine, per saved profile. They never leave your network. The Claude API call is the only outbound traffic.

Each Claude conversation pins to one SAP system; switch profiles between conversations with /sap-login --switch. Subagents inherit the pin, and the session broker enforces connection isolation so a DEV request never hits QAS.

Yes. We detect Unicode vs non-Unicode and convert CJK source via ADODB so uploads never garble.

Yes — and /sap-gui-probe + /sap-gui-skill-scaffold lets us build the supporting skill in days. We probe your custom screen with natural-language scenarios and scaffold a working draft from the captures.

Everything runs on your developer workstation. The Claude API is the only outbound call (and you control which model and key).

So you can audit it, fork it, never be held hostage. Your operational dependency is on your team, not on us.

SAP GUI Scripting enabled (server + client). Optional: SAP NCo 3.1 for RFC features. RFC load-balanced login (Message Server + Logon Group) is supported for large landscapes.

It reads your Customer Brief and runs in three modes: BUILD (spec → deployed code), FIX (open + repair an existing object), DEPLOY (push a .abap file with TR + DDIC + ATC handled). It always asks before deploying and never bypasses ATC findings.

Yes — the sap-migrate plugin runs a brownfield custom-code conversion as a tracked campaign: it inventories your custom (Z/Y) objects, overlays runtime usage (SCMON, UPL, or ST03N workload) so you retire what is unused instead of paying to remediate it, runs the S/4HANA-readiness ATC, and triages findings into remediation tiers — auto-fixing the mechanical ones on a sandbox after a dry-run review. It also executes the retirement of the unused objects behind a signed sign-off gate and an audit ledger, and can revert a deployed fix if one needs rolling back. It is the newest part of the toolkit and we run it with you on a sandbox first.

Yes — that is what the v0.7.x hardening releases set out to satisfy. Reads stay read-only; every mutation goes through SAP's own write APIs; executing or scheduling a report always asks for explicit confirmation first (a report is never assumed read-only); the migration campaign's human gates (scope sign-off, dry-run review) are enforced in code, not just prompts, so a skipped review cannot be recorded as progress; retiring custom code writes a signed audit ledger (object · backup · transport · verified-gone · owner) behind a hard approval gate; and /sap-doctor probes which SAP authorizations the logged-in user holds against a documented capability matrix (docs/security.md), so least-privilege gaps surface before a run rather than after. Credentials are DPAPI-encrypted on the workstation and never leave your network.

The /sap-diagnose suite is read-only and safe to point at production. From a single anchor (a time window, user, job, or short dump) it fans out across ST22 dumps, SM13 update failures, SM12 locks, SLG1 application logs, and SM37 jobs, correlates the evidence, and ranks root-cause hypotheses. From there /sap-fix-incident can close the loop — but only on custom (Z/Y) code, and never on the production system itself: it reproduces the defect in a failing ABAP Unit test, applies a minimal patch, proves it green, and deploys the fix to a DEV system behind a transport, proposing the diff before it writes anything.

Driven by paying customers' needs. The latest release (v0.7.2) adds the runtime lane — run an ABAP report foreground or background over an RFC fast-path with variants and ad-hoc values (sap-run-report), manage the background-job lifecycle end to end (sap-job: schedule / status / log / spool / cancel / delete over SM36 + SM37 + RFC), and transfer files between workstation and application server (sap-file-transfer, CG3Z / CG3Y) to close the file-interface test loop: upload → run → download → diff. All of it sits behind a new confirm-to-run rule — a report is never assumed read-only — and was verified live on S/4HANA and ECC, Japanese logon included. The same release synced the abap-developer agent to the current catalogue (an offer-only runtime verification after deploy, AI semantic review, module-pool completion, a runtime-defect fix lane) and made the Japanese customer brief first-class: the quality-bar gate now parses JA briefs natively. Before that, v0.7.1 was a discoverability consolidation — overlapping skills folded into mode/flag dispatch for a sharper catalogue with fewer commands to learn — plus a headless compiler-level ABAP syntax gate the deploy skills run before an object is inserted. v0.7.0 added execution + assurance to the S/4HANA migration campaign (signed, audited decommission; workload usage fallback; drift detection; unit-test exit gate; scripted revert; batched ATC), the first clean-core codegen lane (sap-gen-cds, ADT-free CDS views), and enterprise-adoption hardening (authorization preflight, documented security model, governance gates enforced in code). Before that (v0.5.0–v0.6.8): the sap-migrate engine, the diagnose → fix closed loop, transport-to-production, AI semantic + security review, ABAP Unit generation, a self-improving error knowledge base with a first-pass-yield KPI, and broad false-success hardening across ECC + S/4HANA and EN/JA/ZH logons. Next: deeper SD/MM agent coverage, RAP behaviour + OData generation on top of the CDS lane, and a managed ATC / readiness dashboard.

No. sapdev.ai uses your developer's own SAP Dialog license through the standard GUI Scripting and RFC interfaces — exactly the same way the developer would interact with SAP manually. The plugin is just a faster keyboard. No service accounts, no cloud-side caching, no aggregated indirect access. We recommend confirming this with your SAP licensing team before formal engagements.