ARTEX (Artex) is software that connects large language models to coordinate security inspection planning and tool execution. On October 8, 2026, the author announced the cessation of updates, a transition to closed source, and the discontinuation of future external distribution and maintenance support. Installation guides written on the premise that public repositories and distribution images would continue to be available now require re-verification of their applicability conditions.
Even if you have already secured sources or public archival repositories, it is difficult to immediately change the installation path. You must first verify what the acquired files are, from what point in time, what rights and conditions are attached, and who will modify and maintain them. This article shares the meaning of the announcement and the results of access verification, and outlines how to interpret existing installation guides and the order of reviewing archival copies.
The verification date is October 9, 2026. This article reviews the official announcement and public repository information, and is not a review of successful installation of new archival copies or actual security inspection performance measurements.
Featured image: AI-generated conceptual diagram. It is not a reproduction of an actual repository screen or execution environment.
1. Scope of Information Available from the Author’s Announcement
The author’s GitHub profile announcement on October 8 explains the background of misuse cases and states that the project will no longer be updated and will transition to closed source. It also includes that new versions will not be distributed externally, nor will maintenance support be provided in the future. The explanation regarding misuse and development intent here should be read as the author’s stated position. It is not independent evidence to prove the full circumstances or legal responsibility of a specific incident. Author’s Announcement
What changes with this decision is the public development and support that can be expected from official channels in the future. It does not imply that all files received in the past have simultaneously disappeared, or that existing copies have automatically become inoperable. Conversely, the presence of old copies does not mean that official maintenance will continue.
Practically, a crucial question arises: who will identify and fix new issues when they occur? To continue reviewing a project whose public maintenance has ceased, users must be able to directly manage dependencies, change history, and execution conditions based on a specific version they have secured. This is not an assertion that new vulnerabilities have been found in that version, but rather a judgment that future review responsibilities and support channels have changed.
2. Announcement and Download Errors Are Different Evidence
The announcement outlines future operational policies. An HTTP response is the result of accessing a specific address under specific conditions. While both can help understand the current situation, one does not explain all causes of the other.
Around 9:10 AM KST on October 9, access verification showed that the original repository, the target release path, and ARM64 ZIP download returned HTTP 404. In the same verification, anonymous query and pull attempts for a specific ARM64 manifest of the official Docker image ended with HTTP 401. The table below shows the results for the verified paths and is not a blanket judgment for all versions or all platforms.
Therefore, the scope of what can be stated now is that it has not been confirmed that installation can proceed by simply following the existing official download paths. Rather than immediately using ZIP files of unclear origin or alternative images upon encountering an error, it is better to first organize the necessary distribution package and verifiable evidence.
Reconstructed based on official documents. This is a conceptual diagram distinguishing policy and response observations, based on the Author’s Announcement and Registry Authentication Flow. Access observations do not guarantee the status of all distribution packages.
3. How to Interpret Existing Overview Articles and Installation Guides
The previously published ARTEX Overview and Introduction Boundaries explained the system’s configuration and security review items based on publicly available data at the time. This article is not a follow-up to re-confirm incident analysis or evaluate tool performance, but rather addresses the situation where public distribution and maintenance conditions have changed. Reading the verification date of the previous article alongside this announcement date allows for distinguishing the subject and timing of the explanations.
The installation guide prepared as of October 5 was based on a specific commit and Compose configuration of the official repository at that time. Compose is a tool that collects execution settings for multiple containers into a single file. While the source pinning and image identifier recording in that guide remain useful review methods, the premise that original repository cloning and image downloads are still possible must be separately verified.
Before applying existing installation guides, you must re-verify the original download address, image provider, CPU platform to be used, and the required version. Distinguish between guides that compare settings at a specific point in time and records of successful installation in the current environment, and if using a new archival copy, review it according to that copy’s conditions.
Even if a source folder remains locally, it does not mean that it is ready for execution. Container images, language packages, databases, and build tools may be required externally. Conversely, even if an image remains, it is difficult to determine if it is the same program without knowing what source and settings it was built with. Source preservation, buildability, successful startup, and functional verification are distinct stages.
4. Finding a Public Archival Repository Does Not Mean the Original Has Been Restored
A fork refers to a copy branched from another repository. In practice, some repositories are linked via GitHub’s fork feature, while others have their history moved and preserved in a separate repository. The timing of acquisition and subsequent changes are more important than the fact that the names are the same.
On October 9, public GitHub API queries allowed access to the following three locations. These are a list of investigation candidates and not a recommended list verified for safety or successful installation. Repository pages and default branches may change later, so commits should also be recorded during review.
[WRIMO_MD_TABLE_1]Two candidates were not marked as official forks in the API at the time of inquiry, while the archiveproject candidate was marked as a fork. This marking provides information about GitHub’s repository connection relationships. It does not verify the originality of the code or the presence of malicious changes. [Public API: mhtsec · Hinln · archiveproject
For example, an archival copy with only the README changed and one with the automatic update address changed have different scopes of review. For the latter, it is also necessary to check where new executable files are received after installation. If there is no reference file to compare with the original, instead of writing “identical to original,” you should record the acquired commit and the range of comparable files. This article does not claim that code review or installation verification for all three candidates has been completed.
During this verification process, an archival public fork starting from the mhtsec archival copy was also prepared. This material preserves the original v0.3.15 commit e6ec56999175509551a1e43a3ee3b053d0941bd9 and tags. The fact that the history remains is separate from the success of new installations or functional verification. The installation itself has not yet been completed.
5. What is Different About the Korean Alternative Candidate artex-ko?
If you desire Korean screens and results, you can review the community localization project jiwoochris/artex-ko. While archival forks focus on preserving original history, artex-ko is a version that adds Korean localization for screens, documents, and user-facing output. It is not presented as an official successor version from the original author or a safety-verified alternative.
The verified code sets the default display language to ‘ko’ and separates Korean and Chinese message files. The agent prompt includes a langDirective() instruction to use natural language in Korean for user-facing output. This is not a method that translates all internal guidelines, code, URLs, and original technical data. The fact that language directives were confirmed in the code is different from a guarantee that all models will always respond accurately in Korean. Screen Language Settings · Output Language Directive Code
The reviewed Korean version commit is 9e1b227d73a6881c1455b0e5ee0595e669474ed2. The preserved upstream change history includes 0.3.14 and subsequent Unreleased changes. This is not used as a basis to conclude that it is identical code to the original v0.3.15. The exact basis must be confirmed by comparing the commit to be used with the scope of upstream data. Upstream Change History Archival Copy
The current README indicates that the default Compose has issues with quick start due to referencing the original image, and that the Korean Docker image distribution is in preparation. The operational verification of the source build path is the repository operator’s explanation, not an installation result reproduced in this article. Therefore, even if you choose the Korean version, you must first verify the path to obtain the executable. Korean README
The license is indicated as AGPL-3.0, and change history and maintenance documents are also provided. The existence of such materials does not substitute for a long-term support promise or independent security verification. Model responses, permissions, external transmissions, and update paths resulting from Korean localization must be separately reviewed for the chosen version. This article did not actually install or run artex-ko. LICENSE · Korean Version Change History
6. What to Pin Before Installation: Commit, Files, Images, Conditions
A commit is a value that Git uses to identify the state of files at a specific point in time. Since a branch name can point to a different location with the next modification, it is recommended to record the source to be reviewed as a pair of the repository address and the full commit identifier. If you have data obtained from the original, check the list of changes against the baseline commit, and do not substitute comparison with copies that merely have the same file names.
The verification order can be divided as follows:
- Source and Scope: Record from which repository, when it was obtained, what commit it is, and whether it is an archival copy including history or just a source bundle.
- Changes: Examine not only the README but also files related to Dockerfile, Compose, dependencies, model connections, update paths, and tool permissions. Read file names and actual changes together.
- Distribution Artifact Connection: Verify if images and executables were built from the reviewed source, who supplies them, and if they support the relevant CPU platform.
- Hash and Archiving: Record the hash of the acquired files to compare if they are the same files later. If the distributor’s checksum and the files were received from the same untrustworthy source, merely matching the two values does not prove the origin.
- Usage Conditions: Preserve the LICENSE, copyright notice, separate declarations in the README for that commit, and the conditions of included third-party components together.
For containers, verify the digest, which is a hash identifying the image content. Tags like ‘latest’ can later point to different content. Pinning the digest helps select the same content when re-pulling, but it is not a verification that the content is harmless. For multi-platform images, you must also distinguish between the digest identifying the entire manifest list and the digest of a specific platform image. Docker Image Digest Documentation
Verification results are more useful for re-review when recorded as short entries like the following, rather than long declarations of success. Below is a template, not an actual installation record.
출처 저장소: 검토 대상 공개 저장소 URL
소스 기준: 확인한 전체 커밋 식별값
비교 범위: 대조한 기준과 파일 목록 / 대조하지 못한 범위
사용 조건: 해당 커밋의 LICENSE와 관련 고지
실행물: 공급자, 플랫폼, 파일 해시 또는 이미지 digest
검증 범위: 정적 검토 / 빌드 / 시작 / 모델 응답 / 도구 권한
유지보수: 담당자, 업데이트 기준, 중단·복원 방법
Reconstructed based on official documents. This is a review order compiled based on GitHub Licensing Guide, Docker Digest Documentation, and Docker Security Documentation. The fact that a next step has been taken does not resolve previously unverified items.
7. License Indication is the Starting Point for Original Text Verification
The fact that something is publicly readable must be distinguished from conditions that permit copying, modification, and redistribution. While the API of the queried candidates showed license information marked as AGPL-3.0, automatic classification alone cannot determine the conditions for all files intended for distribution. You must actually verify the LICENSE and copyright notice of the selected commit, as well as the conditions of included dependencies and individual files.
The author’s announcement of public discontinuation alone does not uniformly determine the rights of all past distribution packages, nor does it conclude that all forks are illegal or usable without any restrictions. GitHub’s guide also distinguishes between repository public/fork relationships and license conditions. This article is not the result of a legal review of each archival copy, and especially if you plan external redistribution or service provision, a separate review based on the original terms you have secured is necessary. GitHub Licensing Guide
Even when archiving, if only the code is kept and notification files are omitted, the basis for later verification is reduced. Conversely, if a fork operator adds a new LICENSE file, it does not automatically clarify the rights of all originally included code. You must verify the timing of changes and their scope of application, and uncertain files should be marked as outside the scope of review.
8. Execution Verification Should Be Conducted Separately in a Dedicated Research Environment
Even after verifying the source and conditions, there is no need to immediately run it on a work machine. Agents like ARTEX that handle files and tools have varying access scopes depending on the execution account, shared directories, and network settings. Docker containers have isolation features, but sharing host directories or control sockets and granting excessive permissions weakens their boundaries. Docker Engine Security Documentation
Start the review in a separate research virtual machine and do not connect business sources, browser profiles, or authentication files. Simply writing “do not access external networks” in the tool does not block network access. Distinguish between necessary model destinations and other external connections, and verify the allowed communication scope in the execution environment.
Verification should not be bundled into a single success. Separately record whether settings can be read, whether processes start with the reviewed executable, whether the screen opens, whether responses to synthetic inputs are received from the selected model, and whether necessary restrictions and approvals function before tool execution. If only a server health response was received, then only server verification is complete. Do not extend this to mean that model responses or the entire tool approval path have been verified.
If external models are used, input can be transmitted externally even from a local program. For the initial verification, use synthetic text instead of actual customer data or operational logs, and simultaneously check storage location, logging settings, usage, and shutdown methods. This procedure is a standard for future reviews and does not mean that this article has actually installed the archival copy or passed all these items.
9. The Current Selection Criterion is Maintainability, Not Obtainability
The discontinuation of ARTEX public distribution does not mean that all past explanations were incorrect. However, the assumption that official downloads and maintenance would continue to be available has changed. When reading existing installation guides, verify the reference date and re-examine current accessibility from the original acquisition stage.
The role of an archival copy is to preserve data from a specific point in time. It does not guarantee a reproducible execution environment or safe operation. You can proceed to the next judgment only when you have verified the source, commit, conditions, changes, and executables, and can record the scope verified in a separate environment.
If the evidence is insufficient, it is more reasonable to stop the review and compare other maintained tools rather than increasing alternative download paths. If you continue archival research, you must also define modification responsibilities and update criteria. Separately recording whether files have been secured, operations have been verified, and future maintainability is possible is the most necessary check in this change.
References
Verification Date: October 9, 2026. The status of repositories and distribution paths may change thereafter.
- ARTEX Author’s Announcement — GitHub Profile: Announcement on October 8, 2026.
- Existing ARTEX Overview and Security Introduction Boundaries: System description at the time of previous verification.
- mhtsec/ARTEX Public API, Hinln/ARTEX Public API, archiveproject/ARTEX Public API: Query for public archival candidates.
- Archival Public Fork: For preserving original history; does not imply completed installation or safety verification.
- Korean Community Alternative Candidate artex-ko: Verification of localization scope, underlying data, distribution path, and usage conditions.
- Target Release Path for Verification, Target ARM64 ZIP for Verification: Subject to access observation; does not imply current download availability.
- Docker Registry Authentication Flow.
- Docker Image Digest.
- GitHub Repository Licensing Guide.
- Docker Engine Security.
Leave a Reply