Laravel 12 - model attributes not shown by default in `php artisan tinker` interactive shell (PsySH 0.12.14)

[andvaranaut]

Laravel Version

12.39.0

PHP Version

8.4.14

Database Driver & Version

No response

Description

Usually, if you use an expression which returns a Model, a Collection and such, it is shown in the REPL:

Psy Shell v0.12.10 (PHP 8.3.6 — cli) by Justin Hileman
> User::first()
[!] Aliasing 'User' to 'App\Models\User' for this Tinker session.
= App\Models\User {#6200
    id: 1,
    name: "admin",
    fullname: "Admin",
(............... rest of the model ...............)
    created_at: "2025-08-07 16:32:46",
    updated_at: "2025-08-07 16:33:18",
  }

However, in a recent Laravel 12 project, that stopped happening automatically for Models, Collections and such, even though using eg. ->getAttributes() works, and that the attributes are accessible:

Psy Shell v0.12.14 (PHP 8.4.14 — cli) by Justin Hileman
New PHP manual is available (latest: 3.0.0). Update with --update-manual
> User::first()
[!] Aliasing 'User' to 'App\Models\User' for this Tinker session.
= App\Models\User {#6112 …8}
> User::first()->id
= 1
> User::first()->getAttributes()
= [
    "id" => 1,
    "name" => "Admin",
    "email" => "admin@test.test",
(............... rest of the model ...............)
    "created_at" => "2025-11-24 13:05:28",
    "updated_at" => "2025-11-24 13:05:28",
  ]
> 

This is happening in a recent Laravel 12 installation, which installed the most recent stable version of PsySH (0.12.14). This seems to be a regression in PsySH, as reverting to PsySH 0.12.10 fixes the issue. Other than that, I have had no success trying to get PsySH 0.12.14 to work.

Steps To Reproduce

• Install new Laravel 12 project
• Create any model (eg. User)
• php artisan tinker + User::first()
• The model attributes should be shown

[github-actions]

Thank you for reporting this issue!

As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.

If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.

Thank you!

[crynobone]

Unfortunately, we are unable to control the output configured by PsySH. You can still see the output of $user using the following:

[PJTech-UK]

This is a result of the issue being discussed here: bobthecow/psysh#512

TL;DR
The owner of Psysh has acknowledged the knock-on effect of the change and is holding a constructive debate to figure out the best way forward.

In the meantime you can (at least, you can on Laravel 10 - I don't know about newer!) pin Psysh to version 0.12.12 which is last-known-good for this problem:
e.g. composer require psy/psysh:"0.12.12" --with-all-dependencies
But remember to watch the issue and unlock the version once a fix is released ;-)

[jasonmccreary]

I can confirm locking psy/psysh version 0.12.12 works on Laravel 10 and higher. I agree this is not a long-term solution. But given their maintainer seems unwilling to revert this massive downstream change, it's kind of all we have short-term.

Hopefully they will readdress this change. If not, part of me wonders if this may be an opportunity to own tinker a bit more with a fork...

[bobthecow]

But given their maintainer seems unwilling to revert this massive downstream change

I think we've probably been misunderstanding each other if that's what you got from our conversation.

I am willing to revert it, and I've said several times that I'd rather revert it than make it configurable. I do want to know if there's a way to improve it before doing that, and I'd welcome your thoughts on the matter, if you want to share them.

[andvaranaut]

Thanks for the input and for the pointers! I must say that having a 7-year old feature request in PsySH break the Tinker workflow was not on my bingo card. :)

I can confirm that downgrading PsySH fixes the issue in Laravel 12. I have done so, and hopefully will be able to unpin it down the line.

@bobthecow besides thanking you for your great work in PsySH, I think that part of the problem is that there is no surefire way to know whether a command is not "meant for inspection" - identical (to PsySH) commands may be meant for inspection or not depending on a number of factors outside its control or knowledge.

It's probably difficult to convey without trying it for yourself, but believe us - in the Laravel world, essentially every command you type in the shell is "meant for inspection" (at least in the sense that you want to know the return value). When you do something like '$user = User::first()' you really want to see what you're setting $user to. Specially when you have been doing so for years and it breaks out of the blue.

This is all probably a byproduct of Laravel's own opinionated choices, which in this case might be clashing with PsySH's. I'm sure the Laravel shell would be happy to pass a configuration option to PsySH, but you have stated that you would rather not have this as something configurable. In that case, I'd say that the new behavior is a rather serious issue for Laravel usage - probably serious enough that somebody would eventually fork PsySH over it, as suggested by @jasonmccreary . (Not that you necessarily care, or even have to care - I'm just trying to convey what the change means in Laravel terms, to the best of my ability).

[PJTech-UK]

I've added some further analysis against bobthecow/psysh#512 - It feels more appropriate to discuss in detail there because it is the home of the code which is affecting Tinker.
I've tried to understand what's changed and make some constructive suggestions about how it could be fixed.

[PJTech-UK]

@bobthecow Has kindly reverted his change in Psysh in order to unblock the issue with Tinker:

Whatever direction we end up going with this, the current iteration isn't working out for people and is causing a lot of frustration, so I've reverted it in v0.12.15 (which was just released).

I've installed this new version by requiring it without a version constraint (e.g. composer require psy/psysh --with-all-dependencies) and it has successfully restored the original behaviour to Tinker.