Claude cannot edit a 1C configuration directly in the database: it is stored in a binary form. There is one working route. Export the configuration to text and XML files through 1C:EDT or the Configurator, tell Claude Code about the project in a CLAUDE.md file, and after every edit check the result in 1C itself. The model writes and edits code in the built-in language noticeably worse than in popular languages, so code review here is a mandatory step, not a formality.
Why 1C does not work like an ordinary repository
In a Python or TypeScript project the code sits in text files, and Claude Code reads them directly. In 1C the configuration by default lives inside the database in binary form: forms, modules and object metadata are packed in a format that cannot be read line by line or edited in a text editor.
Hence the first condition for vibe coding in 1C: turn the configuration into a tree of ordinary files that Claude Code can handle like any other project.
Two ways to export the configuration to files
1C:EDT
1C:Enterprise Development Tools, a development environment built on Eclipse, stores the configuration as separate text and XML files rather than as one binary database. An EDT project is easy to put in git: each metadata object (a catalog, a document, a register) sits in its own set of files, and the diff of a commit reads almost like one in an ordinary software project.
If the team has already moved to EDT, this is the easiest place to start: the repository is already text, and no separate export is needed.
Exporting the configuration to files through the Configurator
The classic Configurator has a menu command, "Configuration → Dump configuration to files". It turns the contents of the database into a tree of text and XML files on disk. Modules in the built-in language are saved as plain text, object metadata as XML.
This route does not move the team to EDT for good. It gives a one-off or regular snapshot of the configuration in a form that a tool like Claude Code can read. After the edits, the configuration is returned with the reverse operation, "Load configuration from files".
How Claude Code works with 1C sources
After the export, Claude Code sees a file tree as in any project: it enters the directory, reads the structure and edits the files it needs. Only the content is different. Modules in the built-in language sit in separate text files, not mixed with form markup, so a request like "add a check that the attribute is filled before the document is saved" comes down to editing one module file, and that edit is visible in the diff before you accept it.
The logic is the same as in ordinary vibe coding: state the task concretely, let the model make the edit, read the diff, run a check. Only "run" in 1C does not mean running a test in CI, but loading the changes back into the Configurator and checking there.
CLAUDE.md: configuration context for the model
A CLAUDE.md file in the root of the exported project noticeably raises the accuracy of generation. It closes the model's main gap: it knows neither the business logic of your configuration nor its internal conventions. It is worth describing:
- Metadata structure. Which catalogs, documents and registers exist in the project and what they are for, even briefly.
- Naming conventions. How procedures, functions and variables in the built-in language are usually named. Then the model will not suggest a style that stands out from the rest of the code.
- Limits on edits. Which objects must not be touched without approval, for example a standard solution that the vendor updates and that must not drift from the original.
- Commit and code review format. Who checks changes, and how, before they go to the production database.
The more concrete the description, the less Claude has to guess at context it objectively does not have.
Checking the result in the Configurator
An edit from Claude Code must not go to the production database without a manual check. The minimum cycle:
- Read the diff of the changed module in full, not at a skim.
- Load the changes back into the database with "Load configuration from files" in the Configurator, or by syncing EDT.
- Check the syntax with the platform's own tools: invalid code in the built-in language will not pass the configuration check.
- Walk through the scenario by hand in 1C:Enterprise mode: open the relevant document or data processor and confirm that the behavior matches the task.
- Only then mark the changes as ready to move further along the pipeline: the test database first, the production one after.
Skipping the manual check in 1C is especially risky where an edit touches document posting or calculations: an error in such logic does not show at once and can pile up in the data.
Limits: the model knows the 1C platform worse
The 1C built-in language and the platform itself are represented in open code sources far less than Python, JavaScript or Java. The practical conclusion: Claude errs more often in platform-specific details (names of object model methods, the finer points of working with registers and document posting) than in tasks in mainstream languages.
That does not make vibe coding in 1C useless. The share of code review in such a project has to be higher than on a popular stack, and the size of an edit per iteration smaller. Ask the model for one logical step at a time: one check, one attribute, one event handler, instead of rewriting a whole module.
How to connect Claude Code to the exported configuration through codexkey
Setting up Claude Code for 1C is the same as for any project. Only the working directory differs: it is the configuration exported to files, not an ordinary code repository.
export ANTHROPIC_BASE_URL="https://api.codexkey.online"
export ANTHROPIC_AUTH_TOKEN="sk_cdx_your_key"
export ANTHROPIC_DEFAULT_OPUS_MODEL="claude-opus-5-5[1m]"
export ANTHROPIC_DEFAULT_SONNET_MODEL="claude-sonnet-5[1m]"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="claude-sonnet-5"
cd /path/to/exported/configuration
claude
A key of the form sk_cdx_... is created in your codexkey account, in the "API keys" section. Payment is by actual token usage with top-ups from 1 dollar, and no subscription is required. A step-by-step Claude Code installation for Windows, macOS and Linux is covered in the Claude Code documentation.
FAQ
Can I use Claude Code right inside the 1C Configurator?
No. Claude Code works with ordinary files on the file system and does not embed in the Configurator interface. You first export the configuration to files, edit it outside, and then load it back.
Do I need 1C:EDT for vibe coding, or is a plain export enough?
EDT is more convenient for steady work: the configuration is stored as files there from the start and lives naturally in git. A one-off or periodic export through the Configurator also works, but you have to repeat it by hand before each editing session.
Does Claude understand the 1C built-in language?
Yes, the model recognizes the syntax of the built-in language and the general logic of working with metadata objects, but less well than languages with more training data. Expect more mistakes in platform details and budget time for checking.
How do I load the changes back into the database after Claude's edits?
With the Configurator's reverse operation, "Load configuration from files", or by syncing the EDT project with the database, depending on how the original export was done.
Is it safe to trust Claude with business logic in 1C?
It can write a draft of the logic. But changes that touch document posting, calculations or register movements should not be accepted without a manual check in 1C:Enterprise mode: an error in such logic does not show at once.
Does this work with standard configurations such as 1C:Accounting?
Technically the export and the editing work the same way. However, standard configurations are updated by the vendor, and your own edits in them can conflict with an update. Such changes are usually moved into extensions rather than made directly in the standard solution.