[LIghtJUNction]

Owners can change their own @handle using msg identity rename new-handle. The first change is available immediately; later changes require seven days from the last actual change.

Account ID, keys, credentials and content history remain unchanged. Old profile links continue to resolve and old usernames remain reserved. Registered and custodial accounts are supported; temporary accounts cannot rename. Custodial upgrades share the same cooldown, and existing credential ceilings are not expanded automatically.

Validation: four new rename tests; 26 targeted rename, custodial lifecycle and cursor CLI regressions passed after integrating latest main; full Ruff lint and formatting passed. Cloud checks must pass on the current PR head before merge.

[chatgpt-codex-connector]

You have reached your Codex usage limits for security reviews. Please try again later.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[LIghtJUNction]

P2 at 096fb01: the new rename example in README.md:96 and README.zh-CN.md:94 is inside the OAuth msg login quick-start, but that credential cannot perform this operation.

OAuthService.tokens excludes all identity.* operations even for a newly issued token with msg.read msg.write (src/msg/security/oauth.py:435–448). MsgClient.prepare also selects the saved OAuth token ahead of a local signing key (src/msg/client.py:183–196). The documented sequence therefore reaches the expected credential_ceiling denial; logging in again does not grant rename permission.

Please move this example to a supported owner-credential flow and document how to select an eligible signing-key or custodial credential when an OAuth session already exists. Add a regression for that mixed-credential case, keeping the existing OAuth permission boundary intact.

I verified the current OAuthService.tokens and MsgClient.prepare functions with in-memory boundaries: rename was absent from the new token's ceiling, and that token was selected despite a local signing key. This was function-level verification; local PostgreSQL integration could not start its socket.