github / github/spec-kit

[Bug]: Codex integration rewrites existing config.toml outside manifest/status tracking

Open
#4,563 1 comment 0 reactions 0 assignees View on GitHub
bug-assess severity-medium triage-must-have
Dominant language
Python
Stars
137k
Forks
12.3k
Avg merge
2d 7h
Merged PRs (30d)
155

Description

## Bug Description

On Windows, installing the Codex integration rewrites an existing tracked `.codex/config.toml` even when there is no semantic Codex event configuration to add. The file is not included in the Codex or Spec Kit managed manifests, so `specify integration status --json` reports a healthy/clean state while Git reports the repository as dirty.

The important issue is not CRLF by itself: an existing tracked file is mutated outside the managed/observed surface exposed by manifests and status.

## Steps to Reproduce

On Windows PowerShell, in an existing Git repository:

```powershell
[IO.File]::WriteAllText(
'.codex/config.toml',
'project_doc_max_bytes = 200000',
[Text.UTF8Encoding]::new($false)
)
git add .codex/config.toml
git commit -m 'Add existing Codex config'

specify init --here --force --non-interactive --integration claude
specify integration install codex

git diff -- .codex/config.toml
specify integration status --json
```

The test used the standard CLI installed from PyPI in an isolated Python virtual environment. No generated files were patched.

## Expected Behavior

One of the following would make ownership observable and coherent:

1. A no-op Codex integration install preserves the existing config byte-for-byte when it has no fragment to add; or
2. If `.codex/config.toml` is intentionally rewritten/managed, the touched file is represented in the relevant manifest/status surface, and status reports modification consistently.

## Actual Behavior

The tracked file changes from no final newline/LF state to CRLF with a final newline:

```diff
-project_doc_max_bytes = 200000
+project_doc_max_bytes = 200000\r
```

`git diff --numstat` reports `1 1 .codex/config.toml`, while `specify integration status --json` reports:

```json
{
"status": "ok",
"installed_integrations": ["claude", "codex"],
"multi_install_safe": true,
"missing_managed_files": 0,
"modified_managed_files": 0,
"invalid_manifest_paths": 0,
"findings": []
}
```

Inspection of v1.0.6 shows the Codex integration declaring `.codex/config.toml` as its event config file, and the TOML merge path writing `existing.rstrip() + "\n\n" + fragment + "\n"`. On Windows, the text write translates the newline sequence. The generated `codex.manifest.json` and `speckit.manifest.json` do not list the pre-existing `.codex/config.toml`.

## Specify CLI Version

`1.0.6`

## AI Agent

Codex CLI (multi-install test also included Claude Code)

## Operating System

Windows 11, AMD64, PowerShell; Git worktree

## Python Version

Python 3.12.14

## Error Logs

There is no CLI error. The unexpected evidence is the Git diff combined with a clean `integration status --json` result shown above.

## Additional Context

- Installing Claude first did not modify `.codex/config.toml`.
- Installing Codex second without `--force` caused the config rewrite.
- No `.gitattributes`, post-processing wrapper, or compatibility patch was added.

AI assistance disclosure: this report was drafted and filed by OpenAI Codex on behalf of the reporter. The reproduction, file diff, generated manifests, and CLI status were collected from a real isolated canary and checked before filing.

Contributor guide

Open the contributing guide

Research direction

Start with the `specify integration install codex` entry point and inspect the TOML merge path described for v1.0.6. Compare how `.codex/config.toml` is handled against `codex.manifest.json` and `speckit.manifest.json`, then reproduce the Windows case. Done means a no-op install preserves the tracked file byte-for-byte or makes ownership and status reporting consistent.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli, tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.