[Bug]: Concurrent permission/batch-reply corrupts ~/.mavis/permission.json and breaks all disk tools mid-session

[fuzzystripes]

Summary

On MiniMax Code / MiniMax Agent desktop (macOS), concurrent writes to ~/.mavis/permission.json during parallel Agent / background-task work can leave the file as invalid concatenated JSON. After that, every local disk tool (bash, read, write, glob, grep, etc.) fails for the rest of the session with a JSON parse error. This looks like a tool-access / permission failure to the user, but the root cause is a corrupted permission store.

Environment

Item	Value
App	MiniMax Code (bundle display name; CFBundleIdentifier com.minimax.agent)
Version	3.0.48 (CFBundleVersion 3.0.48.78)
OS	macOS (Apple Silicon)
Runtime	Mavis / local pi-agent
Permission store	~/.mavis/permission.json
Logs	~/Library/Logs/MiniMax Agent/main-*.log
Date of incident	2026-07-12 (local)

Severity

High — mid-session total loss of disk tooling for all parallel background agents until the permission file is manually repaired. Agents cannot write deliverables; users see opaque tool errors.

Symptoms (as seen by agents)

After the corruption event, every tool call returns the same error (wording stable across multiple background tasks):

Unexpected non-whitespace character after JSON at position 293 (line 11 column 2)

Examples from background-task output:

• “From a certain point onward, every tool call in this session returns Unexpected non-whitespace character after JSON at position 293”
• “Every tool call (bash, read, write, glob, grep) returns Unexpected non-whitespace character after JSON at position 293 (line 11 column 2)”

Tools worked normally earlier in the same multi-agent session; failure began mid-run (not at cold start).

Root cause (local diagnosis)

~/.mavis/permission.json was left as more than one JSON document concatenated, plus a torn shell-command fragment. Independent Python json.loads on the same file fails at the same offset:

JSONDecodeError: Extra data: line 11 column 2 (char 293)

Corrupted file shape (redacted paths; structure preserved)

First object was valid, then extra JSON tails + a torn bash-permission fragment were appended:

{
  "allow": [
    "bash(task_query status:*)",
    "bash([\"chmod\",\"644\",\"/tmp/<sandbox>/.../sample.txt\"])",
    "bash([\"/bin/rm\",\"-f\",\"/tmp/<sandbox>/.../sample.txt\"])",
    "fs(/tmp/**)"
  ],
  "deny": [],
  "ask": []
}
 ],
  "deny": [],
  "ask": []
}
<path-fragment>/<tool>.sh <args> 2>&1)"
  ],
  "deny": [],
  "ask": []
}

• File size while corrupt: 426 bytes
• First valid object ends just before char 293; garbage starts with ],
• File mtime at corruption: 2026-07-12 07:32:48 local
• SHA-256 of corrupt backup available privately on request (not needed to diagnose)

This is not a macOS TCC / Full Disk Access issue. The permission gate cannot parse its own allow-list, so disk tools fail.

Correlation with concurrent permission writes

From ~/Library/Logs/MiniMax Agent/main-*.log, a burst of simultaneous local-runtime permission replies occurs immediately before the file mtime:

[HH:MM:SS.mmm] permission/batch-reply
[HH:MM:SS.mmm] permission/batch-reply   (×5 more, same millisecond window)
[HH:MM:SS.mmm] batch-reply status=200 bytes=68 (×6)
[HH:MM:SS.mmm] permission/batch-reply (×3 more, ~40s later)

Protocol path observed:

app://./minimax-desktop/api/v1/permission/batch-reply
→ /minimax-desktop/api/v1/permission/batch-reply

Hypothesis: permission.json is updated with a non-atomic multi-writer read-modify-write (or overlapping writes without a lock). Parallel Agent Team / background tasks that each trigger permission prompts, then a bulk “allow” / batch-reply, race on the same file and produce torn/concatenated JSON.

The torn trailing fragment is consistent with a bash-permission pattern mid-write (interrupted or interleaved serialize path).

Reproduction steps (observed pattern)

1. Open MiniMax Code desktop on macOS (3.0.48).
2. Start a long multi-agent / parallel background-task session that repeatedly needs tool permissions (bash + fs under project paths and /tmp).
3. When multiple permission prompts accumulate, approve them in bulk (permission/batch-reply) while several agents are still running.
4. Observe mid-session failure: all subsequent disk tools return the JSON parse error above.
5. Inspect ~/.mavis/permission.json — file is invalid JSON (extra data after first object).

I do not yet have a minimal single-command repro outside Agent Teams, but the log + file mtime correlation is strong.

Impact

• All local FS tooling dead until the file is fixed.
• Parallel background agents lose the ability to write reports; they fall back to inline chat output only.
• User-visible framing is “tool access errors for disk ops,” which misdirects toward OS permissions rather than a local config race.

Workaround

1. Quit MiniMax Code.
2. Back up the corrupt file.
3. Rewrite ~/.mavis/permission.json as a single valid object (or reset to empty allow/deny/ask).
4. Relaunch; re-approve permissions as prompted.

Example minimal valid store:

{
  "allow": [],
  "deny": [],
  "ask": []
}

Expected behavior

1. Concurrent permission approvals must not corrupt permission.json.
2. Writes should be serialized (mutex / single-writer queue) and atomic (write temp file + rename).
3. On load, if JSON parse fails, surface a clear recovery UI (“Permission store corrupted — Reset permissions?”) instead of returning a raw JSON parse error on every tool call.
4. Ideally retain last-known-good content or refuse to overwrite with a non-parseable result.

Suggested fix direction

• Single-writer lock around read-modify-write of ~/.mavis/permission.json.
• Atomic replace: write permission.json.tmp → fsync → rename over target.
• Validate JSON before and after write; never leave a non-parseable file as the live store.
• On parse failure at tool gate: one structured error + recovery path, not per-tool stack noise.

Related signals (separate issue, noted only)

After tools failed, some sessions also hit a token-plan usage limit error (product code 2056). That is orthogonal to the permission-store corruption and should not be mixed into this fix.

Related community reports

Other desktop permission-path failures exist (different symptoms), e.g. community “Permission service unavailable” reports. This issue is specifically local file corruption of the allow-list, not gateway reachability.

Attachments available privately on request

• Corrupt file backup (426 bytes)
• Relevant window of the main process log around the batch-reply burst
• Background-task logs quoting the exact parse error

Happy to provide additional redacted logs or test a beta build that serializes permission-store writes.

---

Privacy note: This report intentionally omits absolute home paths, usernames, project names, emails, tokens, and device identifiers.

[iamagenius00]

Thanks for the detailed report. We’re looking into this and plan to address it in an upcoming update. We’ll share any updates here.