Stop AI Inventing AutoLISP Functions: Free Allowlist

On 15 December 2025, in the Autodesk forum thread Microsoft CoPilot AI can write AutoLisp coding, a user called SamBensonL4GSH asked a straightforward question: “I know that you can add knowledge sources to Microsoft Co-Pilot, does anyone have any good ones that they’ve used for theirs or would recommend?”

Kent1Cooper quoted that in full and added one line of his own, square brackets and all:

[Is it possible to embed the entire AutoLisp Reference in there as a “knowledge source,” so it won’t make up functions, use incorrect arguments, etc.?]

Nine minutes later, CodeDing answered him:

I’ve tried. It makes it better, but still often confuses functions from Common Lisp as useable for AutoLisp. But I have noticed that as these newer AI models come out they do get much better at writing AutoLISP.

That is the whole exchange. Two working practitioners identified the fix and one of them had already tried it. It helped. It did not cure. In the seven months since, nobody has published the list itself in a form you can actually paste into a chat window.

So here it is: autolisp-function-allowlist.txt — 485 function names taken from Autodesk’s AutoCAD 2026 AutoLISP Reference, grouped by family, with the traps labelled.

Why AutoLISP is unusually exposed to invented function names

Every language has this problem. AutoLISP has it worse, for three reasons that have nothing to do with AI.

There is no linter sitting between you and the drawing. There is no import statement to resolve, so nothing fails at load time because a module was missing. And a .LSP file is evaluated as it runs — a bad name inside a branch that only fires on, say, an arc rather than a line will sit there quietly until somebody picks an arc. Autodesk describes what happens then: if no *error* handler is defined, “AutoLISP evaluation stops and displays a traceback of the calling function and its callers.” That is your first notification. On a live drawing.

Now consider who is most likely to be pasting AI-generated code. AutoCAD LT for Windows only gained AutoLISP in the 2024 release, and Autodesk is explicit about what came with it: “Visual LISP integrated development environment (IDE) and VLIDE/VLISP commands are not available in AutoCAD LT for Windows”, and “Debugging with the AutoLISP Extension in Visual Studio Code is not supported in AutoCAD LT for Windows”. No IDE, no step debugger. The seats with the least tooling are the seats where the first draft goes straight into the command line.

The forum record on invented names is long and consistent. Kent1Cooper again, back in October 2024: “There have been numerous Topics raised here based on problems with AI-generated AutoLisp code [more commonly from ChatGPT] that was really way off — using assumed but non-existent function names, supplying incorrect arguments, etc.” DGCSCAD, in the same thread, on a routine he was extending: “I had it add MLeaders, but that was full of made-up function definitions. I’ll be trying a different approach.” Over on CADTutor in June 2026, a poster called Least put it in one line about Copilot: “it keeps using LISP functions that aren’t supported in AutoLISP, or ACAD-only functions that don’t work in BCAD.”

What is in the file

The names were pulled page by page from the AutoCAD 2026 AutoLISP Reference — the non-alphabetic page, then A through Z — and sorted into six groups. The groups matter more than the total.

That split is doing real work. Autodesk’s own guidance names three prefixes, not four: “These functions have names that begin with vla-, vlax-, and vlr-… Before you can use any of these functions, you must load the AutoLISP extensions with the following function call: (vl-load-com)”. The vl- family is not on that list. If your model has been told which group a name belongs to, it has a fighting chance of getting the (vl-load-com) line right, and Autodesk is blunt about the cost of omitting it: “If your application does not call vl-load-com, the application may fail.”

Note the hedge — may fail. If something earlier in the session already loaded the extensions, the code works by luck on your machine and dies on a fresh session down the hall.

The Express Tools trap

This is the detail that makes the file worth downloading rather than scraping the reference yourself.

Autodesk’s A Functions Reference page carries 81 names. Fifty of them are acet- functions — acet-str-replace, acet-ss-drag-move, acet-file-copy and the rest — sitting in the same alphabetical index as angtos and assoc, with no wall between them.

Scrape that page naively and you have handed the model fifty names that are not core AutoLISP at all. They belong to Express Tools, a separate install, and Express Tools is not part of AutoCAD LT. A routine built on acet- calls will be perfectly valid AutoLISP on the machine of whoever wrote it and fall over on the next seat along.

It is the same class of failure Least described — code right for one product and wrong for another — except this time the model did nothing wrong. The reference told it those functions exist. Our file labels the group and says plainly: do not use these unless you know the target machine has them.

The AutoCAD LT exclusion list

The old shop wisdom that “vla- doesn’t work in LT” is out of date and worth dropping. Autodesk’s own words for LT 2024: “Most VL*, VLA*, VLAX*, and VLR* functions are supported, but the use of third-party automation libraries is not supported in to AutoCAD LT.” (The “in to” is Autodesk’s typo, not ours.)

What is genuinely absent is the object-instantiation family. Autodesk’s high-level summary of unsupported functions, verbatim:

• vlax-create-object
• vlax-get-object
• vlax-get-or-create-object
• vlax-import-type-library
• vla-GetInterfaceObject
• “VLA* functions related to creating and modifying 3D solid and surface, helix, material, multiline objects among others that can only be created in AutoCAD”

Plus two more from the same page that catch AI output regularly: “entmake, entmakex, and entmod functions only allow for the creation and modification of objects supported in AutoCAD LT”, and “AutoLISP functions exposed by custom ObjectARX and Managed .NET programs can’t be used”.

Those five names are on the allowlist, because they are real AutoLISP functions — and listed again at the foot of the file under a separate LT heading, so you can tell the model which product you are on.

If a routine has to run on mixed seats, Autodesk documents the runtime guard: “This can be done using the PROGRAM system variable, a value of acadlt is returned for AutoCAD LT.” Their guard expression, verbatim:

(if (/= (strcase (getvar "PROGRAM") T) "acadlt")

Wrapped into something a routine can use:

(defun c:DETAILTOOL ( / )
  (if (/= (strcase (getvar "PROGRAM") T) "acadlt")
    (progn
      ;; full AutoCAD only from here
      (vl-load-com)
      ;; ... work ...
    )
    (prompt "\nThis routine needs full AutoCAD, not LT.")
  )
  (princ)
)

An allowlist does not make code portable

It is easy to read a function list as a compatibility guarantee. It is not one.

Autodesk’s vl-load-com reference page carries a Supported Platforms line reading “Windows only; not available on Mac OS or Web”. Everything downstream inherits that. A routine can use nothing but names from this list, be flawless AutoLISP, and still be dead on AutoCAD for Mac or the web app the moment it reaches for a vla- call. command-s carries no such restriction — it is documented as “Windows, Mac OS, and Web” — which is the sourced reason to prefer the command form where either will do.

How to use it

Paste the file into the chat before you ask for anything, then give the model the rules. Something like this, adjusted for your seat:

Below is the complete list of AutoLISP function names that exist,
taken from Autodesk's AutoCAD 2026 AutoLISP Reference.

Rules for everything you write in this conversation:
1. Use ONLY names from this list. If a name is not on it, it does
   not exist. Do not invent one, and do not use Common Lisp
   functions - this is AutoLISP, not Common Lisp.
2. If the task needs something not on the list, say so instead of
   guessing at a function name.
3. I am on AutoCAD LT for Windows 2026. Do not use anything from
   the EXPRESS TOOLS (acet-) group, and do not use any name in the
   "NOT SUPPORTED IN AUTOCAD LT" section at the foot of the list.
4. Any routine that uses vla-, vlax- or vlr- must start with
   (vl-load-com).
5. Declare every local after the slash in the defun argument list,
   with a space after the slash.
6. Localise *error*, restore any system variable you change on both
   the normal and the error path, wrap the work in one UNDO group,
   and end with (princ).

[paste autolisp-function-allowlist.txt here]

Rule 1 is the one CodeDing was reaching for. Rule 3 is the Express Tools and LT trap. Rules 4 to 6 are hygiene, and they belong in the prompt because the allowlist cannot enforce them.

What this does not fix

CodeDing’s result stands: “It makes it better, but still often confuses functions from Common Lisp as useable for AutoLisp.” Constraining the vocabulary constrains the vocabulary. Nothing more.

The clearest demonstration is Kent1Cooper’s four-point breakdown of a piece of ChatGPT code in an older thread: entsel used where a selection set was needed, an if whose else-branch spans eleven lines with no progn around them, foreach pointed at a selection set instead of a list, and a MOVE call whose displacement coordinates were not wrapped in a (list). Every function name in that routine was real. Every one was used wrongly. As Kent put it: “The (foreach) function [line 31] is for stepping through a list, not a selection set such as (ssget) returns.”

martti.halminen named the underlying issue in the same thread, two years earlier: “Seems the fundamental problem here is that the system doesn’t know the syntax and semantics of IF, so it doesn’t know when to close the parentheses, and when to use PROGN to group commands for the correct semantics.” A word list does nothing about that.

Nor does it touch the dialect confusion Henry C. Francis described on the Civil 3D board in 2023 — that the AI “doesn’t yet have a full knowledge of the limitations/differences in Autolisp vs LISP and VLX vs ActiveX”. Knowing a name exists is not knowing which dialect it belongs to.

And it does nothing about hygiene: the undeclared locals, the missing *error* handler, the object snaps that never get put back. Autodesk on globals: “This can lead to unpredictable behavior and it can be very difficult to identify the source of a problem.” Lee Mac on the snap half, from the drafter’s end: “Ever used a program only to discover some time later that your Object Snaps have been mysteriously cleared?”

For that half of the job, the checklist is in our AutoLISP code review post, and the pattern of what actually goes wrong is in the failure taxonomy. Nothing on this page has been run in AutoCAD; it is a reading of Autodesk’s documentation and the forum record, not a test report.

One last note on where the vendor is. AutoCAD 2027 shipped a new Autodesk Assistant in tech preview, “beginning to leverage Model Context Protocol (MCP)”. Autodesk also say exactly what it is for: “In this release, that capability is focused on alignment with CAD standards.” The words AutoLISP, LISP, script and macro do not appear in that launch post at all. Nobody is coming to fix the function-name problem for you. A text file and six lines of prompt will have to do.

More on the language in our AutoLISP tutorials and routines index. For working code to hold AI output against, there are over a hundred in the free LISP routines library.

References

1. Autodesk forums, “Microsoft CoPilot AI can write AutoLisp coding” — Visual LISP, AutoLISP and General Customization Forum. Thread opened 25 October 2024.
2. Kent1Cooper, message 9, 15 December 2025 — the “knowledge source” question, in reply to SamBensonL4GSH.
3. CodeDing, message 10, 15 December 2025 — “I’ve tried. It makes it better…”
4. Kent1Cooper, message 3, 25 October 2024 — “assumed but non-existent function names”.
5. DGCSCAD, message 5, 25 October 2024 — “full of made-up function definitions”.
6. Kent1Cooper, message 8, 13 January 2024 — the four-point defect breakdown, in “Help with OpenAI ChatGPT generated Autolisp code”.
7. martti.halminen, message 7, 14 December 2022 — on IF, parentheses and PROGN.
8. hencoop (Henry C. Francis), “How ChatGPT explained my Autolisp problem”, 2 May 2023 — Civil 3D Customization Forum.
9. CADTutor, “AI taking over” — AutoLISP, Visual LISP & DCL forum, June–July 2026. Least’s post, 20 June 2026.
10. Autodesk, “What’s New or Changed with AutoLISP”, AutoCAD LT 2024 AutoLISP Developer’s Guide — LT limitations, exclusion list and the PROGRAM guard.
11. Autodesk, “vl-load-com (AutoLISP/ActiveX)”, AutoLISP Reference (AutoCAD 2024) — “Windows only; not available on Mac OS or Web”.
12. Autodesk, “About Loading Extended AutoLISP Functions”, AutoLISP Developer’s Guide (AutoCAD 2024) — which prefixes need vl-load-com.
13. Autodesk, “command-s (AutoLISP)”, AutoLISP Reference (AutoCAD 2024) — “Windows, Mac OS, and Web”.
14. Autodesk, “About Using the *error* Function”, AutoLISP Developer’s Guide (AutoCAD 2024) — traceback behaviour when *error* is nil.
15. Autodesk, “About Local and Global Variables”, AutoLISP Developer’s Guide (AutoCAD 2024) — “unpredictable behavior… very difficult to identify the source of a problem”.
16. Autodesk, “A Functions Reference”, AutoLISP Reference (AutoCAD 2026) — 81 names, 50 of them acet-.
17. Autodesk, “V Functions Reference”, AutoLISP Reference (AutoCAD 2026) — 182 names, the vl-/vla-/vlax-/vlr- bulk.
18. The AutoCAD Team, “AutoCAD 2027: Redefining How You Create, Collaborate, and Deliver”, 25 March 2026 — Autodesk Assistant tech preview and its stated 2027 scope.
19. Lee Mac, “Error Handling” — the localised *error* handler and state restore pattern.